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(57) Abstract: An industrial control user interface provides a flexible, extensible architecture for the provision of real-time process 
data to a state-of-the-art user interface, using MS HTML as the underlying rendering engine. The architecture of the interface provides 
a user interface that is designed to harness key industry standard technologies in an open, adaptable, architecture that facilitates the 
technological convergence of disparate HMl products. The preferred embodiments offer open display page architecture via the 

^5 separation of the provision of data and ser\'er specific user interactions from the implementation of individual page elements. The 
only real assumption made about a page element is that it is part of the HTML display page and accessible via the Document Object 

^ Model. 
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TITLE: HUMAN MACHINE INTERFACE 

FIELD OF INVENTION 

The present invention relates to a human machine interface (HMT). 

The invention has been developed primarily for Industrial, Secvirity, Life 

5 Safety, Access Control, Heating, Ventilation and Air Conditioning applications such 
as the monitoring of data generated by industrial processes and equipment, and will be 
described hereinafter with reference to that application. However, it will be 
appreciated that the invention is not limited to use in that particular field. 
BACKGROUND OF THE INVENTION 

10 Remote monitoring of data is Jfrequently used in industrial settings. The desire 

for implementing such monitoring ranges fi-om the need for centralised monitoring of 
relatively complex industrial systems to the convenience of allowing a small nmnber 
of operators to monitor multiple data streams via a single workstation. In many cases, 
it is also desirable that the HMI allow operators to control at least some of the 

15 industrial processes and machines in relation to which the data is being collected. 

Historically, collection and display of industrial data on operator workstations 
has been dealt with on a proprietary basis, with application-specific software linking 
remote data sources with dedicated terminals. Whilst such systems have provided 
satisfactory performance, they are relatively time consuming to design, and relatively 

20 inflexible once implemented. 

Another problem is that individually implemented software solutions are often 
limited in the types of data sources with which they can interface. 

One of the most profound developments of the last five years has been the 
staggering growth of the internet. This growth has changed public perceptions about 

25 the availability of data, about what to expect in a user interface, and how open and 
interoperable computer systems should be. Standalone computer systems are no 
longer acceptable to the market - the increasingly networked world is setting the pace 
and scope of change. 

In addition, this growth has led to a huge shift in development focus for 

30 practically every software organisation. The web has become the ubiquitous data 
delivery mechanism, and as software organisations focus their energies on harnessing 
its potential, the technologies which imderpin its success are being pushed forward at 
ever-increasing rates. Where once the web was not mature enough to support 

5DOCID: <WO 0195041 A 1_L> 



wo 01/95041 



PCT/AUOl/00706 



-2- 

mission-critical functions, such as major financial transactions or process control, it is 
clear that this is no longer the case. 

It is this growth which is driving investment into user interface technology, as 
the major stakeholders seek to establish the intemet as a viable business platform. As a 
5 result, current teclinological trends have meant the underlying technologies are 
becoming increasingly more appropriate to the field of industrial process control. 

The development of what may be loosely termed "intemet technologies" has 
been extremely rapid, and has a very short history: 

" December 1993: Only 200 known http servers existed. 
10 ■ December 1994: First W3C meeting. Over 200 members, charter to promote 
interoperability. 

■ October 1996: OLE Controls 96 Specification published. Promotes 
lightweight, windowless controls suitable for the web environment, and intended 
to add increasing sophistication to browser capabilities. 

15 ■ December 1996: Cascading Style Sheet specification. Introduced 2D 
positioning, size, colour, font attributes. 

■ July 1997: HTML 4.0 specification. Included scripts, objects, firamesets, 
intemationalisation. Browser technology advanced appropriately. 

■ September 1997: Dynamic HTML, Document Object Model. Full access to 
20 the HTML object model, providing web pages with unprecedented power and 

flexibiUty. 

■ September 1998: Intemet Explorer 5.0 Beta 2. Includes Vector Markup 
Language for vector graphics capabiUties. 

■ late 1999: OfiBce 2000 to use HTML/XML as document format for all suite 
25 products. Microsoft look to include sufficient fimctionality in HTML for it to be 

suitable for use by Visual Basic forms engine. 

In parallel with these developments has been an increasing awareness that 
HTML's origins as a language intended to store presentation information means its 
abiUty to store and represent data is severely hmited. This limitation has led to the rise 
30 of XML, or extensible Markup Language, intaided to work in concert with HTML to 
provide a means of storing both data and presentation information. 
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It was these trends that led the applicant to consider the suitability of such 
technologies for industrial control systems. 

The development requirements of an industrial control system indicate clearly 
that known web browsers are not suitable for the operator environment of an industrial 
5 control system. They may be acceptable for casual use, but the operator environment 
has specific requirements, such as restricted navigation, support for industrial 
keyboards, alarm and status indication, and security. 

The partial solution to a number of these issues may be provided using a 
software package sold and marketed by Microsoft®. In particular, Microsoft® si5)ply a 
10 rendering engine used in Intemet Explorer (known as MSHTML), for use by third-party 
developers wishing to integrate HTML rendering capabilities into their applications. 
While this software package can represent a usefiil tool for system designers, its generic 
nature ensures that it will not automatically integrate or interact with other applications. 
Further although the invention in some aspects will be described in relation to this 
15 software package, it will be appreciated that other browser techniques may be used. 

Any discussion of the prior art throughout the specification should in no way 
be considered as an admission that such prior art is widely known or forms part of 
common general knowledge in the field. 
DISCLOSURE OF THE INVENTION 
20 It is an object of the present invention to overcome or ameliorate at least one of 

the disadvantages of the prior art, or to provide a usefiil altemative. 

According to a first aspect of the invention there is provided a Human Machine 
Interface (HMI) including: 

a display page including a plurality of display page elements; 
25 a data source manager including a plurality of data source components; and 

a binding engine which transfers data and commands between the data source 
components and the display page elements. 

Preferably, the display page fiuther includes a plurality of infrastructure 
components. More preferably, the data source components are server system specific 
30 data source components. Even more preferably, each display page has its own 
corresponding binding engine. 

Preferably also, the individual data source components are shared by more than 
one binding engine. 
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In a preferred form, the display page acts as a container for the page elements 
that make up the display page and provides the primary user interface thread of 
execution. More preferably, the page elements include any one or more element that 
can be included in an HTML file. More preferably, the page elements include one or 
5 more of: 

ActiveX controls; 

VML graphics elements; 

HTML elements; 

HTML scriptlets; and 
10 Java Applets. 

Preferably, the display page is constmcted using a mixtvire of standard HTML 
and XML tags. More preferably, the HTML describes presentation aspects of the 
display page - that is the page elements - while the XML tags describe what data is 
required for the page and how that data is to be applied to the page. Even more 
15 preferably, the infrastructure components assist with the parsing of the XML content 
of the display page, the delivery of data to the display page and the initiation of server 
commands from display page elements. 

In a preferred form, at run time, the display page appears as an instance of a 
standard Document Object Model (DOM). More preferably, the DOM is the standard 
20 for the industry to which the HMI is applied. 

Preferably, the DOM provides the destination for data provided by the binding 
engine. More preferably, the DOM further provides the basis for the display page 
scripting environment. 

Preferably also, the display pages are capable of being encapsulated and re-used 
25 as encapsulated displays. More preferably, the encapsulation includes the 
parameterisation of any data references in the display page and the addition of 
properties, methods and events that allow the Encapsulated display to act as a fiiUy 
fledged component. Even more preferably, the encapsulated displays are embeddable. 
More preferably still, the encapsulated displays are linked into containing display pages. 
30 Preferably, the display page is HTML based. 

In a preferred form, the data source manager manages a plurality of server 
system specific data source components that encapsulate the details of delivering data 
to and firom particular server systems. More preferably, each data source component 
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presents data from a server system in the form of a hierarchical object model. Even 
more preferably, the data source manager pulls the separate data soxa-ce component 
object models together into a unified data source object model (DSOM) that is used as 
the source of data for the binding engine. 
5 Preferably also, the data source components are informed of the data 

requirements for a particular display page by means of a data source definition that is 
stored as part of an HTML/XML display page file. 

in a preferred form, the server systems include one or more of a variety of 
different server system, a small subset of which includes the server systems provided by 
10 Honeywell Limited and that are known as: 

Plantscape; 

Enteiprise Buildings Integrator; 

TPS; 

TPA; 

15 QCS; 

Uniformance; 
OPC; and 
HCI. 

Preferably, the data binding engine takes the data provided by the data source 
20 object model and qjplies it to the display page. More preferably, the data binding 
engine takes the data provided by the data source object model and applies it to the 
display page m a way defined by binding definitions contained in the HTML/XML 
display page. Even more preferably, each display element that requires data has an 
associated binding definition that defines what data is required for the element and how 
25 it is to be applied to the element 

Preferably also, the data binding engine is able to bind data to any property of 
the DOM. More preferably, the DOM includes the body element and any container 
elements fliat are used to organise ofiier elements on the display page. More preferably, 
the binding engine uses transformations to perform the transfer of data fi-om the data 
30 source object model to the display page. Even more preferably, the transformations 
transfer the data directly fi-om the data source object model to the display page. It is 
also preferred that flie transformations transforms the data as they transfer the data. 
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In a preferred form, the transformations include user written "OnDataChange" 
scripts and data driven page element "dynamics" such as rotation, path animation and 
break point animation. More preferably, the transformations are binary components. 
Even more preferably, the transfoimations are written using an XML syntax and script 
5 code. 

In a preferred form, the binding engine executes in an apartment managed by the 
data source manager and transfers data from the data source object model to the display 
page in a very efficient manner. 

The preferred embodiments of the invention provide an operator framework 
10 built around MSHTML to provide the functionality specific to the needs of an industrial 
control system. Additionally, it has been found that these embodiments, using 
MSHTML as the underlying rendering engine, provide a flexible, extensible 
architecture for the provision of real-time process data to a state-of-the-art user 
interfece. That is, the preferred embodiments make use of synergies that are possible 
15 from the interaction between the operator fi-amework and the rendering engine. Again, 
while the embodiments make use of the MSHTML browser software, other browser 
techniques would be equally applicable. 
BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic overview of the architecture according to the invention; 
20 Figure 2 is a schematic representation of an operator runtime environment of one 

embodiment of the invention; 

Figure 3 is a schematic overview of the display authoring that is utiUsed in 
preferred embodiments of the invention; 

Figure 4 is a schematic view of the authoring environment provided by one 
25 embodiment of the invention; 

Figure 5 is a schematic view of the PlantScape implementation scenario 
provided by an embodiment of the invention; 

Figure 6 is a schematic view of the TPS implementation scenario provided by an 
embodiment of the invention; 
30 Figure 7 is a schematic view of the TPS wearable computer remote cUent 

scenario provided by an embodiment of the invention; 

Figure 8 is a schematic view of the HiSpec implementation scenario provided by 
an embodiment of the invention; 



SDCX;(0: <WO 0 195041 A 1J_> 



wo 01/95041 H ^ PCT/AUOl/00706 



-7- 

Figure 9 is a schematic view of the TPA implementation scenario provided by 
an embodiment of the invention; 

Figure 1 0 is a schematic view of the reuse of configuration components 
provided by an embodiment of the invention; 
5 Figure 1 1 is a schematic view of the seamless transition between systems 

provided by an embodiment of the invention; 

Figure 12 is a schematic view of the general arrangement of these components in 
the architecture of a preferred embodiment of the invention; 

Figure 13 is a schematic view of a data source manager as shared resource 
10 within an embodiment of the invention; 

Figure 14 is a schematic view of the display page structured used in an 
embodiment of the invention; 

Figure 15 is a schematic representation of the data source architecture used in a 
preferred embodiment of the invention;. 
1 5 Figure 1 6 is a schematic view of a data source used in an embodiment of the 

inv^ition and which includes several data references; 

Figure 17 is a schematic view of a data source used in an embodiment of the 
invention and which includes hierarchical data references; 

Figure 18 is a schematic view of the relationship between the data source 
20 manager, the data binding engine and the data somrce; 

Figure 19 is a schematic view of the relationship between a data reference that 
exposes a property, an event and a rowset to a binding object which is part of the 
Hendrix data binding architecture; 

Figure 20 illustrates the broad components in the Hendrix data binding 
25 architecture; 

Figure 21 is a schematic representation of a "thin chent, remote servef system 
provided by an embodiment of the invention; 

Figure 22 is a schematic representation of a "thin client, single node" system 
provided by an embodiment of the invention; 
30 Figure 23 is a schematic representation of a "very thin cUent, distinct middle 

tier" system provided by an embodiment of the invention; 

Figure 24 is a schematic representation of a "very thin client, middle tier" 
system provided by an embodiment of the invention; 
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Figure 25 is a schematic representation of the binding to the global data 
repository used by an embodiment of the invention; 

Figure 26 schematically illustrates the sequence of events upon page callup; 

Figure 27 schematically illustrates the general arrangement of the Hendrix data 
5 source architecture; 

Figure 28 schematically illustrates the components that constitute a data source, 
the main COM interfaces they implement and the main relationships they have with 
other parts of the Hendrix architecture. 

Figure 29 schematically illustrates the typical data source states and the methods 
10 that cause transitions between those states when a data source is being used to provide 
data to a run time UI framework; 

Figure 30 is a UML sequence diagram that illustrates the basic operation of a 
Hendrix data source at run time; 

Figure 3 1 schematically illustrates the typical data source states and the methods. 
15 that cause transitions between those states when a data source is being used by the 
Hendrix display builder; 

Figure 32 is a UML sequence diagram that describes a build mode sequence of 
events in which a new data source is created and configured to have a simple data object 
model consisting of a root data object containing one child data object. 
20 Figures 33 and 34 are a schematic representation of the various components 

used in the Hendrix runtime environment; 

Figure 35 is a schematic representation of the framework binding used in an 
embodiment of the Hendrix architecture; and 

Figure 36 is an illustration of some Windows user interface elements in a 
25 Windowless control.' 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Glossary of Terms 

ActiveX control: a reusable software component exposing its functionaUty 
through COM interfaces. ActiveX controls cannot be run alone and must be loaded into 
30 a control container such as Microsoft Internet Explorer. 
DHTML: Dynamic HTML. 
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DOM: Document Object Model. Industry-standard object model for HTML 
scripting. 

Hendrix; The trademark used to identify the common architecture for the HMI 
systems developed by Honeywell Limited and which is applied to the embodiments of 
5 the invention described in this specification and marketed by Honeywell Limited and its 
associated entities. 

HMI: Human-machine interface. 
HSC: Honeywell Software Center. 
HTML: Hyper-text Markup Language. 

10 MSHTML: Microsoft-suppUed HTML rendering-engine component 

WWW: World-wide web. 
XML: Extensible Maricup Language. 

Binding A particular mapping firom a binding source to a binding target. 
Transformation A component suppUed to the binding engine to transfomi data as 
15 it is transferred from the data source object model to the display page. 

Binding Definition The definition of how to map data firom the data source 
object model on to the DOM. It is a collection of individual bindings. 

Binding Engine The component that maps data from a binding source on to a 
binding target. 

20 CLSID Class ID Unique identifier for a COM object. 

COM Component Object Model. Microsoft-defined standard for binary 
interoperability of components. 

CSS Cascading Style Sheet. 

Data Reference A hierarchical name that refers to an object or property in the 
25 data source object model. 

Data Source A server system specific component that communicates with fee 
server system and provides the data source object model to the binding engine. 

Data Source Connector The server system specific component on the display 
page that connects the display page to the data source manager. 
30 Data Source Definition The server system specific definition of the data required 

by the display page. This definition is understood by the data source and impUdtly 
defines the shape and size of the data source object model. 
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Data Source Object Model An Automation object model containing data 
delivered from the server system. It is the source of data for the binding engine. 

Data Source Manager The component that coordinates the activity of the data 
source components and provides the execution enviromnent for the binding engine. 
5 Display Page An HTML page that contains a data source connector and one or 

more page elements. 

DTD Document Type Definition - used by an XML parser to validate that the 
stmcture of an XML document. 

HTA Hypertext Application - means of constracting a standalone application 
10 from a single HTML file. 

IE5: Microsoft Internet Explorer 5.0. 

Operator Framework: A user interface framework that allows an operator to 
interact efficiently and directly with the server system. 

Page Element: An element in the display page that has properties that can act ast 
15 binding targets, (includes ActiveX Controls, HTML elements). 

Server System: A Honeywell system that is the ultimate source of data for a 
display page. These include PlantScape, TPS, OPC servers etc. 

VML Vector Markup Language - Microsoft's proposal for a standard vector 
graphics format for the Web. 
20 W3C: World-wide Web Consortium. 

XML Scriptlet: Method used to build small, flexible COM objects through a 
combination of XML and script code. A scriptlet may be thought of as a COM object, 
complete with properties, methods, and the capability of firing events. 

APP: Asynchronous Pluggable Protocol. 
25 BHO: Browser Helper Object 

DSM: Data source manager. 

MFC Microsoft Foimdation Classes. This is a C-H- class library mainly used for 
creating WIN32 applications and can be used for creating ActiveX controls. 

ROT Running object table. 
30 Server System: A Honeywell system that is the ultimate source of data for a 

display page. These include PlantScape, TPS, OPC servers etc. 

VB: Microsoft Visual Basic. 
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Introduction 

Some preferred embodiments of the various aspects of the present invention are 
described in Australian provisional patent application no PQ8087 that was filed on 
9 June, 2000. The disclosure in that appUcation is incoiporated herein by way of cross- 
5 reference. 

It should be noted that the applicant's code-name for the embodiments of the 
present invention is "Hendrix", and this code-name therefore appears throughout the 
provisional specification referred to above. While the same name is used in this 
specification, for the purposes of convenience and consistency, it is not intended that the 

10 invention be Umited to any system having a particular trade- or code-name. 

Appendices A to E in the provisional application disclose the detail of various 
preferred embodiments of the present invention. It will be appreciated that the various 
discussions of development requirements and the like should be taken in the context of 
specific issues related to particular products supplied by the appUcant, as well as being 

15 concemed with specific embodiments presently envisaged by the applicant. 

Accordmgly, the information in the appendices should be read as exemplary, and not 
restrictive of the broadest scope of the invention as described and defined in the earlier 
part of the provisional specification. 

To fixlfil the requirements of an industrial control user interface the preferred 

20 embodiments have been developed on the basis oftheHendrix architecture, fiiabroad 
form, it is a flexible, extensible architecture for the provision of real-time process data to 
a state-of-the-art user interface, using MSHTML as the underlying rendering engme. 

The Hendrix architecture provides a user interface that is suited to the demands 
and challenges of tihie next decade and which is designed to harness key industry 

25 standard technologies in an open, adaptable, architecture that faciUtates the 

technological convergence of disparate HMI products. Some important technical 
features of the Hendrix architecture, as exempUfied in the preferred embodiments, 
follow. 

Open display page architecture - the Hendrix architecture separates the 
30 provision of data and server specific user interactions fi"om the implementation of 

individual page elements. The only real assumption made about a page element is that 
it is part of the HTML display page and accessible via the Document Object Model. 
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The provision of data to page elements and the association of server specific 
user interactions with page elements is handled by the Hendrix architecture. This has 
the important effect of widening the set of HMI page elements to include anytiiing that 
can appear in an HTML page. 

5 A further effect of this architecture is that Honeywell page elements are more 

easily reused in contexts outside of the Honeywell HMI for which they were originally 
conceived by virtue of the fact that they do not include any server specific 
implementation. These contexts include, for example, other Honeywell HMIs and non- 
Honeywell applications. 

10 Choice of runtime user environments - the architecture offers a choice of 

runtime user environments, reflecting the need for both controlled and casual access to 
process data. The first environment is a robust, secure operator environment, satisfying 
the distinctive requirements of industrial control user interfaces. The second is a web 
browser environment in which the user treats display pages as they would any other web 

15 page. Both environments utilize commodity fhird-party rendering engines to display 
process data. 

Open, extensible file format ~ the Hendrix architecture centres on a standards- 
based file fomiat, using HTML as its foundation. The file format conforms completely 
to HTML standards, allowing display pages to be rendered by a third-party browser. In 
20 addition, the ubiquitous nature of the file format allows it to be edited in third party 
editing tools, in order to apply specialised functionality to display pages, such as 
complex path animation. 

Component-based architecture - the architecture is entirely component-based. It 
consists of both common components reusable by all Hendrix implementations, and 
25 server-specific components developed as part of each Hendrix implementation. 

Data delivery from multiple sources — the architecture is designed to 
accommodate the delivery of data from multiple Honeywell and other server systems to 
a single display. 

Single authoring tool, customisable for specific server needs — the architecture 
30 does not dictate how display pages are authored, provided they comply with the Hendrix 
file format standard. In the long term, and with the development of third-party tools, 
those tools should be sufficiently customisable to render them appropriate to this role. 
In the short-term, however, the preferred embodiments rely upon the specific 
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requirements of Honeywell industrial control systems and require a proprietary 
authoring tool. This tool utilises commodity third-party HTML editing components 
where appropriate. It is also extensible and customisable, such that it can meet the 
requirements of each server for which Hendrix is implemented. 
5 These features are schematically represented in Figure 1 . Note that this figure 

does not show all components of the Hendrix architecture aad is intended to only 
provide an overview. Issues such as the binding of data from the server data source to 
HTML data, and the actual delivery of data, are discussed elsewhere in this 
specification. 

10 It is worth noting that the architecture does not necessarily dictate that all servers 

be capable of supplying remote data to their corresponding data sources. Some 
embodiments include one. or more servers that satisfy themselves wifli server and 
middle tier (the data source manager and components) on a single machine. It will be 
appreciated that these embodiments still fall within ttie broader Hendrix architecture. 

15 Furthermore, the architecture provides, in some embodiments, remoting faciUties to 
those components which require it. 

The preferred embodiments are designed to provide users with two ways to view 
and control plant information: the operator environment, designed primarily for security 
and reliability, and the web browser environment, where universal, flexible, secure data 

20 access is the prime concem. The operator environment is aimed primarily at operators, 
and is intended to provide a framework tuned to their needs, as follows: 

• Framework screen artifacts (menus, toolbars, command zone, alarm zone, etc.) are 
specific to the server system to which the framework is connected. 

• Page navigation is simple and name-based (i.e. fiill URLs are not required for page 
25 navigation). 

• Provides explicit control of the connection to the server, able to specify screen 
update rates, connection types, and so on. 

• Guaranteed view of data via persistent alarm line and status Une, if required. 

• Robust in the face of page failure - badly-behaved controls caimot compromise the 
30 operator framework. 

• Fast automatic fail over in redimdant systems. 

• Able to be tailored to restrict operator's capabilities (e.g. prevent desktop access, 
prevent shutdown, fiill screen lock, SafeView, operator keyboard, etc). 
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• Seciire access to control of process parameters. 

The browser environment is aimed primarily at managers, engineers and process 
analysts, and is intended to provide a more regular web experience: 

• Navigation is via the normal hyperlinking mechanism, that is, fUU URLs are 
5 required for page navigation. 

• Comiections to servers are implicitly created by "surfing" to a server. Connections 
use default parameters for things like update rates, connection types, and so on. 

• A user has the ability to easily "surf* from system to system. 

• A minimal user interface is, in some embodiments, provided — depending on fhe 

10 system — for issuing commands. This user interface is not persistent and comes and 
goes with flie page. 

• Server connections are cached (for a lunited time) so that security levels are able to 
be maintained across pages. 

• Page URLs are selectively saved in browser favourites. " ' 
15 • Menu and toolbars are the browser's menu and toolbars. 

• Controls on pages facilitate the control of plant data, as well as supplying context 
menus for issuing commands. 

• Fail over is not automatic in redundant systems 

The operator runtime environment, in the context of the Hendrix architecture, 
20 takes many forms in flie different embodiments. These forms depend on the specific 
market and user requirements of each server type. For example, in one embodiment the 
runtime environment for one server consist of a single framework, complete with 
menus, toolbar and alarm zone. However, for another server it is a collection of display 
pages, organized on the screen through the use of a desktop management framework 
25 (e.g. SafeView). It is important to point out that in terms of the Hendrix architecture, 
these frameworks are identical. Data and commands are supplied to and from the 
framework in an identical maimer, and display page management is the same. A thin 
layer differentiates the frameworks for different markets, but both systems fit into the 
Hendrix concept of the "operator framework". By way of example, one embodiment of 
30 ttie invention provides an operator runtime environment as illustrated in Figure 2. This 
is a PlantScape Hendrix implementation. However, in other embodiments use is not 
necessarily made of a PlantScape control but, rather, another Hendrix-compliant system. 
In this way Hendrix inherently provides a level of interoperability and convergence 
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amongst Honeywell HMEs. Note also that there is a distinction between the behavioiar 
of Hendiix-compliant Honeywell controls and third-party controls. While these third- 
party controls are fully integrated into the Hendiix environment, they often do not 
possess some of the advanced functionality of Honeywell controls, such as quality 
5 indication. This additional functionality is provided by the architecture of the invention, 
in that appropriate configuration Hendrix supplied controls is undertaken to complement 
the existing third party controls. 

In other embodiments use is made of an alternative operator runtime 
enviroimient, consisting of multiple display windows, positioned on screen through the 

10 use of desktop management software. Importantly both these runtime frameworks are 
equally valid Hendrix implementations. In fact, the invention was designed with 
alternative runtime frameworks in mind, as it recognizes that different market 
requirements require different user interface frameworks for different server products. 
This is one of the strengths of invention - that is allows the same underlying 

15 architecture to be used to produce extremely flexible, market-specific, user interfaces. 
This flexibility extrads all the way to the web browser environment. In a Hendrix- 
based system, the web browser environment is able to display the same pages as those 
shown in, say. Figure 2, with live data updates. The preferred embodiments thus deliver 
the ability to view process data in a web browser. 

20 Figure 3 illustrates an overview of flie display authoring that is utilised by the 

invention. The key points to note are: 

1 . Displays are authored in a single, common authoring tool, and saved as standard 

HTML files. The definitions for the retrieval of data from various servers are 

saved in the file by tlie authoring tool. 
25 2. Users, where enabled, have the abiUty to add functionality to displays using 

commodity third-party HTML authoring packages. 
3. The display is thai viewed, in either an operator environment or in a web browser. 

In both environments, the display behaves the same, with Uve data updates from 

the servers of interest 
30 4. The data source manager - refer to Figure 1 - through server-specific 

components, manages the real-time retrieval of data from the servers of interest, 

and supplies this data to the displays on the client. 
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This presumes a single authoring tool, with add-in components, for all systems 
in the embodiment to allow it to configure data for the various systems. In other 
embodiments, however, more than one authoring tool is used. Figure 4 illustrates, by 
way of example, an authoring environment that is provided in one of the embodiments 

5 of the invention. 

It should be noted fi-om Figure 4 that the builder requires the ability to configure 
server-specific data access. The Hendrix HMI program allows the use of a single 
builder for industrial HMI products. In some embodiments, this builder is composed of 
server-specific components which allow this data configuration to take place. These 

10 components also allow the builder to be aware of issues such as server redxmdancy, data 
definitions, and server connection details. 

The preferred authoring tool is based around commodity third-party 
components, such as an HTML rendering engine for true WYSIWYG fimctionality. In 
other embodiments, however, use is made of conmiodity authoring packages that are 

15 sufficiently customisable to provide all the authoring fimctionality for Hendrix systems, 
and for the entire authoring tool to be a commodity item. 

Figures 5 to 11 illustrate various implementations of the Hendrix architecture, 
and scenarios in which those implementations are xised. It is important to note that these 
scenarios serve to illustrate the area of interoperability between systems. This 

20 interoperability takes place on a nimiber of levels: 

• At flie control level, the interoperability between system controls is an inherit 
feature of the architecture provided by the preferred embodiments of the invention. 
The architecture fiiUy supports binding process data to third-party controls, so by 
inference any Hendrix HMI supports controls fi'om other Hendrix systems. In 

25 addition, controls built to be aware of the Hendrix architecture will be even fiarther 
integrated into any Hendrix-based operator HMI. 

• At the runtime level, the architecture fiiUy supports the integration of data from 
multiple data sources. Data from multiple HMIs is delivered to a single display 
page, resulting in excellent interoperability between systems. 

30 • At the connection level, the ability to establish a connection to a new server "on the 
fly" means the architecture provides a seamless transition between systems for both 
the casual user and the operator. 
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Another important point that is highlighted by the scenarios of Figures 5 to 1 1 is 
the degree of commonality between them. The Data Binding process connnon to all 
scenarios, for example, is provided by a generic binding engine component that is 
xiseable in any Hendrix HMI system. With such a binding engine implemented it will 
5 become available to all Hendrix implementers. Thus the Hendrix architecture delivers 
one of the most significant goals of HMI convergence and of component-based 
architectures in general: software reuse at the binary level. 

It will be apparent to the skilled addressee, fi-om the teaching herein, that there 
are any number of user scenarios involving interoperabiUty between dijBFerent Hendrix 
10 implementations. The main point to make is that such scenarios are possible, and 
fecilitated by the Hendrix architecture. 

Benefits provided by the preferred embodiments 

The architecture provided by the mvention and as manifest in the preferred 
embodiments, offers a large number of benefits to the operator and the designer of the 
15 systems. These benefits are at both a strategic and a technological level and can be 
broadly categorized into five main types: 

1 . Benefits arising fi^om the way the embodiments use commodity third-party 
technologies. 

2. Benefits arising firom the use of an open, industry-standard file format. 
20 3 . Benefits associated with Hendrix data delivery and data integration 

mechanisms. 

4. Strategic benefits. 

5. Benefits associated with "future-proofing" the industrial operator HMI. 
These five types will be considered in turn and in more detail below. 

25 Use of Commodity Tltird-Party Technologies 

The architecture of the preferred embodiments, the Hendrix architecture, relies 
on commodity third-party technologies for a number of its core mechanisms. Where 
appropriate, these technologies and components provide functionality in areas which are 
not the core business of the system designer. This allows the designer to focus on the 

30 areas where they are able to add the most value, rather than trying to compete in areas 
that are not necessarily within their core competencies. The benefits offered by these 
technologies include: 
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• Casual access to process data via a web browser. This capability is important for 
non-operator users who do not wish, or who are unable, to install fat HMI client 
software on their machines. An important aspect of this capability is the ability to 
view the same display from a process environment in a web browser, not just the 

5 ability to publish process data on the web. 

• Unmatched intemationaUsation features. With the combination of Intemet Explorer 
5.0 and Windows 2000, a Hendrix HMI is able to supply far richer 
intemationalisation features than those currently available in existing HMI systems, 
such as dynamic language switching, changing language mid-line, and rich third- 

1 0 party intemationalisation tools. 

• State of the art graphics rendering. The rendering engine provided by MSHTML is 
one of the best available, functionally more capable than any existing product, and 
likely to continue to improve as the intemet expands. Its animation c^abilities and 
ability to render highly-demanding unages such as 3D graphics, will prove difficult to 

15 match in the coming decade. This is more of an advantage in a non-console operator 
environment. The console operator environment is an area where the elements of the 
display must be as non-distracting as possible, allowing for operators to carry out their 
normal pattern-recognition and action tasks. One example of the application for 3D 
rendering would be visualisation of blast fumace arrays and the displaying of hot 

20 spots in the fumace in 3D. [Note that "advanced graphics rendering" should not be 
seen as limited to such advanced ftmctionality as 3D rendering. The rendering 
capabilities of MSHTML include the ability to render different graphics formats, such 
as JPG and GIF files, and any future graphics formats that come available.] 

• Easy display dq>loyment. Hendrix systems allow leverage to be gained firom 

25 standard deployment mechanisms available to browsers, which are becoming richer 
as the industry progresses. An example is the 7/24 availability (7 days a week, 24 
hours a day) demanded in modem web servers, which now provide advanced 
display replication capabilities to meet these demands. 

• User-definable operator frameworks. Technologies such as Microsoft's Hypertext 
30 Application (HTA) technology facilitate the development of user-definable operator 

fi-ameworks, which are accommodated within the Hendrix architecture. This 
capability, while primarily intended from use by the designer of the architecture, is 
in some embodiments also provided to the users or customers of flie system. 
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• Easy generation of displays dynamically. Standard web technologies such as Active 
Server Pages can be used to generate displays on the fly. Depending on different 
requirements such as operator capabilities (liigh-contrast displays for some 
operators, for example), or daily activities (different displays to reflect different 

5 schedules on an oil pipeline) can resxilt in different displays being built on the server 
and sent to the client. Other examples include the abiUty to generate system 
management displays dynamically using standard mechanisms. 

• AbiUty to integrate with standard value-add offerings for internet products, such as 
e-mail integration objects, transaction components, and messaging components, that 

10 come as standard parts of state of the art web server products. 

' Industry-Standard File Format 

The preferred embodiments are centred aroimd an open, extensible, industry- 
standard file format. Particularly, use is made of a file format in as standard an HTML 
representation as possible, thus reaping the most benefits firom tiie alignment with 
15 industry standards. The use of this file format brings a number of benefits, including: 

• Third-party authoring tool options. The use of a standard file format results in 
multiple options for authoring tools, particularly in the area of roxmd-tripping 
displays. Where a designer's standard authoring tool does not offer the capabilities 
required by a particular customer, such as complex path animation, this functionality 

20 is supplied by editing flie Hendrix display page in a third-party HTML editing tool. 
The ability to edit a designer's display in a third-party authoring tool offers 
imprecedented flexibility to the user of the system. 

• Leveraging of existing knowledge. Using both an industry-standard scripting model 
and industry-standard file format means customers are able to gain leverage from 

25 the rapidly growing pool of expertise in web authoring, graphic design, and HTML 
scripting to produce high-quality process displays. Users of the system provided by 
the invention are able to selectively, and as required, use their favourite graphic 
design team to design their displays, rather than relying on the overall system 
designer for their look and feel. 

30 • The use of a common file format facilitates re-use of displays between different 
systems, thereby helping to protect a user's intellectual property investment. 
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• Display pages are machine-searchable and human-readable. This aspect of the 
Hendrix architecture has a number of benefits, including: 

o The ability to facilitate automated cataloguing and searching of displays by 
customer systems, software applications provided by the provider of the 
system, and third-party tools. 

o Simple text search and replace functionality external to the builder itself. 

o Configuration management: the text-based nature of the file format renders 
it suitable for use in configuration management systems. 

o Custom manufacturing of standard system displays prior to shipping. 

o Ability to preserve user additions to the system displays through the process 
of an upgrade — customisations of system displays can be positioned along 
the lines of a macro that alters the system displays, rather than modifications 
that must be performed on each revision of the displays. 

• Easier conversion to/firom industry standard formats (for example, AutoCAD, 
PowerPoint) into system displays. In many industries, displays are first created in 
AutoCAD, and then have to be transformed to proprietary formats. The adoption of 
HTML/VML as the file format makes this conversion simple. 

• Powerfiil template mechanism through the use of Cascading Style Sheets (CSS). 
The CSS mechanism provides users of the embodiments with the capability to apply 
style to entire suites of display pages. Examples of this fimctionaUty includes: 

o Changing background watermark for an entire set of system diq>lays. 
o Updating one or more icons used on every display to reflect changed 
company logo. 

o Choice of colours to reflect particular customer and/or operator 
requirements, applied across the entire set of displays. 

o On a ship system, the ability to supply fiill-colour displays by day, and red- 
on-black by night. 

o Altering displays according to operator requirements, such as colour 
blindness. 

• Ability to add user-definable structured data to display pages. Current standard for 
this capabihty is through the use of XML. A user is in a position to add customer- 
specific fields that track changes made to that display. This structured data is 
usually stored in the file and made available via scripting. This functionality is 
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immediately accessible by the user simply through the choice of Hendrix file 
format. With a proprietary format, the system designer or operator would be 
required to implement this functionality on a case-by-case basis. 

• The industry-standard file format protects customer intellectual property against 
technological change. With a proprietary format, the operator is responsible for 
migration and incompatibility issues when new file formats are adopted. These 
issues still exist in the case of HTML, but the user base of this file fomiat is far 
larger. While the problem is not completely removed, tihe risk of inadvertence is 
reduced as the number of minds made aware of the issue is far larger. 

• Additional enhancements to web file format standards are delivered for fl-ee. 
Examples of this support - which will be handled by the MSHTML rendering 
engine - include Scalable Vector Gr^hics (SVG) firom the W3C, and Extensible 
3D pC3D) firom the Web3D Consortium. 

Data Delivery and Integration 

The Hendrix architecture is designed for rich data integration capabilities, which 
bring with them the following benefits: 

• Ability to integrate data firom multiple operator or provider systems on a 
single display. 

• Facilitation of remote operation. The capability of remote data binding 
realises the possibility of a thin-client architecture on every system. 
The Hendrix client is then completely scalable, and suited for 
environments firom hand-held PC devices, tlirough to wearable 
computers produced by HTC, all the way to workstations and servers. 
The architecture expands the reach of the user interface like no existing 
HMI. 

• Seamless integration of foreign data sources via the standard HTML 
data binding mechanism. Infoimation firom Oracle, SQL server, or 
even structured data in the form of XML is incorporated into the page, 
as required for the particular application. Foreign data is used in some 
embodiments to drive some properties of an object on a page, while in 
other embodiments use is made also of process data. No ActiveX 
controls are required for this data binding - it takes place natively 
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within the engine itself - and can be bound directly to HTML elements 
such as tables. 

• Better integration between the operator HMI and other business 
systems. Business systems are undoubtedly moving towards greater 

5 integration with the web, which brings the Hendrix HMI closer to those 

systems. The inherent web integration of the architecture, along with 
native HTML data delivery and data binding, provide a rich means for 
integrating business system information - such as order information in 
a manufacturing facility, or web-based corrective action applications - 
10 into the operator HMI. 

Another related aspect is the trend amongst device manufacturers to provide the 
ability to configure their devices (such as temiinal servers or printers) using web-based 
user interfaces. The preferred embodiments allow the user to configure all the devices 
in their system through a single user interface. 

15 Future-Proofing 

The Hendrix architecture is designed to protect the HMI fi*om technological 
change, placing it in a good position to weather changes in the future and thus extending 
its shelf-life. The term "fiiture-proof is, of course, a misnomer. No product is able to 
insure itself against fixture technological change, no matter how advanced it may be, 

20 unless it is able to continually evolve with these changes. Some products, however, are 
better placed to adapt to change, by virtue of their architectures. It is in this area that 
Hendrix offers its advantages, as explained below. 

Note also that "fixture-proofing" has been a promise of previous architectures, but 
in the past has proved to be an elusive goal. The future-proofing offered by the Hendrix 

25 architecture is more extensive than simply the use of the latest software tools, or the 
introduction of open systems. The Hendrix architecture is unique in several areas: 

• It uses commodity third-party components (such as MSHTML) to 
harness the power of technological change that the internet represents. 
Standards change, new ones arise, and new technologies become 

30 available as the intemet develops - and Hendrix is design to grow with 

them all. New technologies will become available almost by default, 
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and new tools will offer capabilities beyond the scope of any one 
organisation's development teams. 

An operator or designer of the system of the invention has no need to 
develop a world-class ActiveX control container, for example, when 
one already exists. The Internet Explorer engine is a control container 
par excellence, and is guaranteed to adapt to upcoming technological 
developments. For example, Microsoft has afready demonstrated the 
next-generation control capabilities slated for Visual Studio 7 (code- 
named '"Rainier"), featuring unprecedented integration between 
controls and their container. This functionality is ahready supported by 
Internet Explorer 5.0, and would come for free in the architecture 
provided by the preferred embodiments of the invention. 
One way to view this is that whenever Microsoft raises perfomiance 
expectations in its own products, any ActiveX control container of our 
own is expected to do the same. By using tifieir components directly, 
each improvement they make instead tums into a direct benefit for the 
system operator and, hence the user. There is a direct flow on effect of 
the technology as extensive redesign is not required to incorporate the 
new features. 

It is component-based, and thus extremely versatile and able to adapt to 
change. When new system features become available (for the data 
binding, authoring, or rendering, for example), only the affected 
components need to be replaced, not the entire system. 
It adds the operator's value to precisely those areas suited to their 
needs, addressing requirements specific to industrial control systems, 
thus ensuring the viability of the operator's products in the long term. 
Hendrix implementations are not threatened by new user interface 
technologies, but assisted by them. For example, as commodity editing 
components and tools become available, the operator simply picks up 
the fimctionality of the authoring tool, as appropriate. With prior 
proprietary systems, this option is clearly not available where the 
equivalent functionality had to be built into the authoring tool by the 
operator, usually at a great cost. 
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• It is closely coupled with industry standards — not just Microsoft 

technologies referred to above - and is designed intentionally to be open 
and extensible. The standards-based nature of the architecture helps 
protect the architecture, with bodies such as the W3C working to ensure 
5 that internet development is an incremental and evolutionary process. 

As previously mentioned, no product is future-proof. The Hendrix architecture, 
however, is designed to be far more adaptive to change than any existing HMI system. 

The Hendrix Architecture Overview 

The Hendrix architecture describes the components and relationships between 

10 them necessary to build a fiiUy functional industrial HMI. The architecture provides the 
infrastructure for the run time support of HMI display pages and frameworks in which 
to view, navigate and interact with them. 

The Hendrix architecture is an entirely component-based architecture in which 
each component in the architecture is a COM object. This approach means that the 

15 architecture is easily partitioned into standard components that are used in all Hendrix 
implementations and server specific components that must be implemraited for each 
server system for which the Hendrix architecture will act as an HMI. 

The foundation of the Hendrix architecture is Microsoft's core HTML rendering 
component known as MSHTML. This component forms the basis of an increasing 

20 number of Microsoft products including Internet Explorer, Outlook Express, Money98, 
MSDN Library, Microsoft Management Console and others. It takes the form of a 
reusable COM object that is available to independent software vendors, such as 
Honeywell, for use in third party products. The latest version of MSHTML, which 
forms the basis of Internet Explorer 5, is positioned by Microsoft as an appUcation 

25 development platform to rival MFC in terms of performance and stability. In addition, 
the latest version of MSHTML includes many new features that are pivotal in making it 
suitable as a basis for an industrial HMI architecture such as the Hendrix architecture. 

MSHTML provides the following HMI capabilities in the Hendrix architecture: 
display file parsing and rendering; ActiveX control hosting; scripting; 2D graphics 

30 primitives (VML); and multimedia and animation services. 

With MSHTML as its foundation, the Hendrix architecture, as implemented in 
the preferred embodiments, achieves two broad goals. The first is to add tiie 
mechanisms necessary to turn MSHTML into an industrial HMI. The second is to 
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structure these mechanisms in such a way as to facilitate convergence amongst the 
various operator HMI products. By adopting the Hendrix architecture the operator is 
able to implement a common HMI framework for its various industrial process control 
systems which mininaise development effort, maximize interoperability of components 
5 between systems and, importantly^ give customers a consistent suite of user interface 
tools with which to operate and manage their plants. 

To turn MSHTML into an mdustrial HMI it is necessary to provide mechanisms 
for data delivery, user initiated commands, navigation, robustness and stability. These 
mechanisms must be available to different classes of users in user interface frameworks 

10 that reflect the needs of each class of user. The personnel that operate the system on a 
day to day basis require a framework with menus, toolbars and guaranteed access to 
alarm and status information. On the other hand, managers of the personnel need more 
casual access along the lines of a regular web browsing experience. 

With these mechanisms in place, the Hendrix architecture allows flie designer 

15 and provider of the system to concentrate on adding value to its HMI in the form of 
specific display page elements (typically ActiveX controls) that allow users to more 
effectively interact with and manage both their plant processes and the systems used to 
control them. The preferred embodiments of the invention also make these controls 
very easy to write. 

20 The three main components in the Hendrix architecture are the MSHTML 

display page containing a nxmiber of display page elements and a small number of 
infrastructure components, the Hendrix data source manager which contains a number 
of server system specific data source components and the Hendrix binding engine which 
transfers data and commands between the data soxirce components and the display page 

25 elements. Figure 12 illustrates the general arrangement of these components. 

The data source manager used ia the preferred embodiments is a resource shared 
by all display pages on the client machine and each display page has its own binding 
engrae. Data source components are also shared by binding engines, although this need 
not occur in all instances. Figure 13 illustrates a data source manager that is used in a 

30 preferred embodiment of the invention. 

The MSHTML based display page acts as the container for the page elements 
that make up the display and provides the primary user interface thread of execution. 
The page elements, in some embodiments, include Honeywell ActiveX controls, third 
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party ActiveX controls, VML graphics elements, HTML elements, HTML scriptlets, 
Java Applets etc. In fact, anything - control, element, or otherwise - that can be 
included in an HTML file counts as a page element in the Hendrix architecture. 

The display page is constructed using a mixture of standard HTML and Hendrix 

5 specific XML tags. The HTML describes the presentation aspects of the display page 
(that is, the page elements) while the XML tags are used to describe what data is 
required for the page and how that data is to be appUed to the page. 

The display page also contains a small number of Hendrix infirastructure 
components that assist with the parsing of the XML content of the display page, the 

10 delivery of data to the display page and the initiation of server commands firom display 
page elements. 

At run time the display page appears as an instance of the industry standard 
Document Object Model (DOM). This object model provides the destination for data 
provided by the Hendrix data binding engine and provides the basis for the display page. 
15 scripting environment. 

Display pages are preferably encapsulated for reuse. This encapsulation 
includes the parameterisation of any data references in the display page and the addition 
of properties, methods and events that allow the encapsulated display to act as a fiiUy 
fledged component. Encapsulated displays are usually either embedded or linked into 
20 containing display pages. 

The data source manager is the component that co-ordinates the delivery of data 
firom the various server systems to the Hendrix architecture. The data source manager 
manages a series of server system specific data source components that encapsulate the 
details of deUvering data to and firom particular server systems. Data source 
25 components are required for Plantscape, TPS, TP A, QCS, Unifonnance, OPC and HCL 
Each data source component presets data firom a server system in the fomi of a 
hierarchical object model. 

The data source manager pulls the separate data source component object 
models together into a unified data source object model that is used as the source of data 
30 for the Hendrix binding engine. 

The data source components are informed of the data requirements for a 
particular display page by means of a data source definition that is stored as part of the 
HTML/XML display page file. The details of the data source definition is a data source 
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component implementation detail. The data source definition is usually the result of a 
"pre-binding" mechanism that turns the human readable data references used in the 
display page into machine readable names that provide for more efficient deh very of 
data at run time or it may simply define the extra infonnation required to deUver the 
required data such as update rates and the like. 

Data source components are used to optionally support indirect data references 
where an item in the data source object model is used as a place holder for particular 
objects in the server system which are specified at run time. This provides a level of 
indirection in the data source that is used to "browse" through objects of the same type. 

The preferred data binding engine takes the data provided by the data source 
object model and applies it to the display page. It does this in a way defined by binding 
definitions contained in the HTML/XML display page. Each display element that 
requires data has an associated binding definition that defines what data is required for 
the element and how it is to be applied to the element 
15 A key feature of the data binding engine of the preferred embodiments is that it 

is able to bind data to any property of the DOM. This includes the body element and 
any container elements that are used to organise other elements on the display page. 

The architecture of the binding engine is component based and uses 
"transfonnations" to perform tlie transfer of data firom the data source object model to 
20 the display page. These transformations allow the transfer of data directiy or transform 
it some way as they transfer the data. Examples of where transformations are used 
include user written "OnDataChange" scripts and data driven page element "dynamics" 
such as rotation, path animation and breakpoint animation. Transformations are 
preferably either binary components or written using and XML syntax and script code. 

The binding engine executes in an apartment managed by the data source 
manager and transfers data firom the data source object model to the display page in a 
very efiScient manner. 

Each server system for which the Hendrix architecture is acting as an HMI has 
its own set of commands that a user may need to invoke. These include commands 
30 directed at the process such as "raise" and "lower'' or at the server system itself such as 
"acknowledge alarm" and "point detail". 

These server specific commands are implemented as methods on the root object 
of each server specific data source component. These commands are executed from 



25 
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page based script code or from server specific *lDehaviours" associated with display 
page elements. 

In addition there are system wide commands that apply across server systems 
such as commands to log on to the system or change security levels. These commands 

5 are implemented as methods on the root of the imified data source object model 

provided by the data source manager. Again, these commands are executable from page 
based script code or from a behaviour associated with display page elements. 

In many circimistances it is necessary to allow users to view display pages 
within some framework that makes the task of viewing, navigation and interacting with 

10 display pages easier and safer. Examples include tiiie Plantscape Station framework 
(that provides a menu, toolbar, alarm zone, status zone, message zone and command 
zone), flie SafeView (which provides window management for multiple displays) and 
the TPA framework (that allows the user to easily navigate between displays). 

The Hendrix architecture itself provides a mechanism for constructing a user 

15 interface fimiework. This is achieved by constructing the framework as a series of 
display pages that manage other display pages. It is easy to construct frameworks that 
contain the usual user interface elements such as menus, toolbars, status lines as well as 
HTML constmcts such as framesets. This makes the repertoire of possible frameworks 
very large indeed. 

20 Hendrix based frameworks in conjunction with SafeView provide a flexible, 

powerful and safe means of delivering the environments needed by users to more 
effectively use an HMI. 

At run time a Hendrix display page is an instance of the industry standard 
Document Object Model (DOM). The DOM contains instances of useftil display 

25 elements such as ActiveX controls, HTML elements, graphics primitives etc. The 
DOM is initialised from an HTML file that specifies the initial content of the display 
page and is created by an authoring tool such as the Honeywell Common Display 
Builder. An HTML parser parses the HTML file and initialises the DOM. A rendering 
engine then renders the DOM in a window. Hendrix uses Microsoft's MSHTML 

30 component for these functions. Figure 14 illustrates the general arrangement of the 
main display page components. 

Once initialised, the page is updated with data from the Hendrix data binding 
engine upon which the HTML rendering engine re-renders the display page so that the 
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user sees the changes to the page (fliis re-rendering behaviour is what is conunonly 
known as *T>ynamic HTML'' or DHTML). The flow of data between the data binding 
engine and the display page is typically bi-directional. Any changes made locally to the 
display page, by the user or by script code, are re-rendered by the rendering engine and 
5 propagated back through the data binding engine. 

In addition to the presentation aspects of the display page defined using HTML 
there are Hendrix specific XML tags in the display page file that define the details of 
what data is required by the display page and how to apply that data to the display page. 

The details of what data is required by the display page axe contained in a series 
10 of data source definitions. There is one data source definition for each type of data 
soxurce component (tiiat is, each type of server system) firom which data is required for 
the page. The details of the data source definition are specific to each type of data 
source component. 

The details of how to apply the data to the page are contained in a series of 
1 5 binding definitions. There is one binding definition for each page element that requires 
data firom the server system. 

The display page also contains a data source connector that establishes 
communication with the data source manager. The data source connector also plays an 
important role in transferring data firom the data binding engine of the preferred 
20 embodiment and in providing "named data access". 

The display page contains components that assist with the parsing and 
processmg of the XML portions of the display page file. 

The display page file is completely managed by a common display builder 
which, in ttiis embodiment is proprietary software developed by Honeywell. This 
25 software produces and maintains both the HTML and the XML content of the file. 

The spUt between the HTML and XML portions of the display page file 
corresponds to a split between the presentation and content aspects of the display page. 
Since the presentation aspects of the display page are expressed in standard HTML, 
third party tools can manipulate the presentation to provide functionality not provided 
30 by the common display builder. Because third party tools will not imderstand the XML 
portions of the display page file the data source definition and the binding definition will 
remain opaque to those tools. 
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The immediately following description deals with the basic display page 
HTML/XML file fomiat, while later description discusses the data source definition and 
binding definition in detail. 

The following example illustrates a very simple Hendrix display page that 
5 contains a single page element. 

<HTML> 

1 <xml:namespace ns— 'um:schemas-honeywell-com:hendrix" 

prefix="HENDRIX"/> 



10 2 <OBJECTID=^T>ata"CLSID="..."X/OBJECT> 

3 <OBIECT ID="HendrixExtensions" CLSID="...">^OBJECT> 

4 <OBJECT ID="Hendrix&ctendedElemenf ' CLSID="..."x/OBJECT> 

5 <OBJECT ID='TlantscapeCommands" CLSID="..."></OBJECT> 



<STYLE> 

6 

url(#HendrixExtensions)} 
7 

url(#HendrixExtendedElement)} 
8 

iu:l(#Plantsc^eCommands)} 

</STYLB> 



HBNDRIXV:* {behavior 
.Hendrix {behavior: 
.PlantscapeCommands {behavior: 



<BODY> 

25 9 <SPANID="Alphal"CLASS='Hendrix; 

Plantsc^eCommands" BINDINGDEF="AlphalBindingDef'> 

</SPAN> 

10 <HENDRIX:BINDINGDEF ID="AlphalBindingDef *> 

<DATA ID="DataRefl" 

30 REF="OPC.Modbus.A100.PV"/> 

<BINDING SOURCE="DataRefl" 
TARGET="PageElement.ImierHTML'V> 

<;/EIElSlDRIX:BESIDINGDEF> 
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<yBODY> 

1 1 <HENDRIX;DATASOURCEDEF ID=="OPC" 

CLSDD=="DA943720-8048-lld2-8ED5-000000000000"> 
5 <SERVERNAME-"modbus"> 

<GROUP UPDATEPERIOD=^»500"> 
<ITEM NAME="A100.PV"/i> 
<yGROUP> 
</SERVER> 

10 <HENDRIX:DATASOURCEDEF> 
<yHTML> 

The file begins with an XML namespace declaration that establishes the use of 
the Hendrix namespace in this file (1). This step is followed by the data source 

15 connector (2) and the two components that assist with the processing of the XML 
content of the page (3 and 4) and a component that implements Plantscape command 
behaviour (5). A STYLE block is used to associate convenient names with the 
infrastructure components (6,7 and 8). The body of the display page then contains a 
single HTML element (9). This SPAN element has a binding definition associated wdth 

20 it (10). This binding definition specifies that the data item OPC.Modbus.Al OO.PV is 
bound to the ImierHTML property of the SPAN element. Finally, there is a data source 
definition for the OPC data soim^e component (1 1) that specifies the details of how to 
get the item A100.PV fi-om the OPC server called Modbus. 

Note tbat in this example there is only one data source definition in the file. In 

25 other embodiments, where the display page requires data from more than one sarver 
system, there are data source definitions for each type of server system. 

The most commonly used categories of display page elemrat are ActiveX 
controls, VML graphics elements and HTML elements. As mentioned elsewhere, the 
ActiveX controls are either or both of Honeywell or third party controls. VML graphics 

30 elements include built in simple shapes such as rectangles, lines, elUpses, arcs etc or 
more complex shape types. HTML elements include the fiill suite of normal web page 
elements such as DIV, SPAN, IMAGE, TABLE, INPUT, OPTION, SELECT etc. 
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The architecture of the invention, as provided in the preferred embodiments, 
allows this wide variety of display page elements to be treated equally with respect to 
supplying data to them from server systems. This is achieved by the binding engine 
assuming most of the responsibiUty for transferring data from the data source 

5 components to the display page elements. The display page elements simply have to 
offer properties to which data can be delivered. A similar situation exists with respect to 
server and system command behaviours. Conmiand functionality is added to page 
elements by the Hendrix architecture without the behaviour having to be expUcitly 
coded into the elements themselves. 

10 This effective separation of presentation, content and behaviour in the Hendrix 

architecture means it is easy to write ActiveX controls that work well in the Hendrix 
architecture. Most controls do not need to worry at all about how data is supplied to 
them or how command behaviours are associated with them. The control designer is 
free to concentrate on the presentation aspects of the control which makes the task of 

15 designing controls much simpler. This also makes the system incredibly robust 

There are, however, a small number of requirements that ActiveX controls used 
as Hendrix page elements must meet to be fully integrated into the Hendrix architecture. 
These fall into two main categories: requirements that make the controls 'Hendrix 
compatible" and requirements that make the controls ^THendrix aware". 

20 The first requirement of Hendrix compatible controls is that they provide 

property change notifications if they are to write changed values back to the server 
system. This is because the binding engine uses these notifications to know when to 
send a new value back to the data source object model. This corresponds to the 
properties of the element being marked as [bindable] in the element's type library. 

25 A page element property that is bindable may support optimistic binding or 

pessimistic binding. Optimistic binding means that the element will simply notify the 
binding engine that the property has changed, after which the binding engine will 
propagate the new value back to the binding source in the data source object model. If, 
for some reason, the value cannot be changed on the server system, for security reasons 

30 perhaps, the data source object model will need to notify the binding engine that the 
value has changed back to the previous value and have the binding engine propagate 
that value back to the page element. 
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In the case of pessimistic binding the page element will ask the binding engine if 
the property value can change. The binding engine forwards this request on to the 
binding source where security considerations etc. can be checked. If the value can be 
changed the page element then changes the value and notifies the binding engine. If a 
5 page element supports pessimistic binding its properties will be marked as [bindable, 
requestedit]. 

The Hendrix architecture supports both types of binding. If a property of a page 
element does not support either type of binding it can only be used for read only data. 

The other requirement of a Hendrix compatible control that allows complete 
10 integration in the Hendrix architecture is that the control be windowless so that 

command behaviours are associated with the element. If the element has a window, for 
example an ActiveX control that does not conform to the OC96 specification, tibie 
command behaviour will not receive user input 

Note that page elements that do not meet these requirements are still usable in 
15 the Hendrix architecture, but they will suffer &om the two limitations noted above. 

Hendrix aware controls are controls that know about the Hendrix architecture 
and that use it to then- advantage. An example is a trend control that knows how to 
interact with the data binding engine to access more historical data as the user scrolls the 
trend. Another example is a combobox control that directly request the delivery of its 
20 Ust only when the user cUcks on the control to drop the Ust down. 

Another important aspect of Hendrix aware controls is fiiat they are designed 
with properties that correspond to properties on the server supphed data source object 
models so that the binding of data to the control is as direct as possible and hence as 
efficient as possible. 

25 In short, Hendrix aware controls are the controls that work best with the Hendrix 

architecture. Non-Hendrix aware controls are still usable in the preferred embodiments, 
but may require small amounts of script code to effect full integration. 

The Hendrix architecture encapsulates the mechanisms used to communicate 
with a server system at run time. These mechanisms include the delivery of data to the 
30 Hendrix architecture and the routing of commands back to the server system. 

A Hendrix data source is a component that encapsulates a server system at run 
time. It consists primarily of data reference objects that encapsulate the details of • 
delivering particular data items firom the server system. The data references are 
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organised into a data reference object model, which is used by the Hendiix data binding 
architecture as input. The data reference object model is also accessible by display page 
script code and Hendrix transformations. The data reference object model also provides 
the means by which conrmiands are routed to the server system. Commands are 

5 implOTiented as methods on data references within the data reference object model. 

The deUvery of data from a server system involves many server system specific 
details. For this reason data sources need to be developed for each type of server 
system. Even within a single server system there may be different types of data items 
that are delivered in different ways which means data reference objects need to be 

10 developed for each type of data item in each server system. 

The data source manager is the Hendrix component responsible for coordinating 
the delivery of the data required by display pages. It manages both the server system 
specific data sources and the binding engine that transfers the data from the data soiirce 
components to the display page. Figure 15 illustrates the general arrangement of these . 

15 components. 

When a display page is called up, the data source manager accepts URLs for the 
data source definitions and binding definitions from the data source coimector on the 
display page. It parses the data source definitions and instantiates the necessary data 
sources. It then passes the data source definitions to the data sources so that they can 

20 construct their data reference object models. The data sources then pass references to 
their individual object models back to the data source manager which then makes them 
available to the binding engine together with the binding definitions for the page* The 
binding engine then binds the data references in the data reference object models to the 
display page according to the binding definition. The data sources are then instructed 

25 by the data source manager to begin delivering data. 

A Hendrix data source implements a memory resident hierarchical data 
reference object model. This object model consists data reference objects. These data 
reference objects provide the means by which data from the underlying server system is 
presented to the Hendrix architecture. 

30 A data source appears as in-process COM object to the data source manager. In 

order for a data source to be usable on a machine other than the server system itself it 
must include a mechanism for populating its object model over the network. The 
mechanism to do so is an implementation detail of each data source. 
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The main task of a data source is to provide an initialisation service to the data 
source manager. This initialisation service allows the data source manager to pass a 
stream containing a data source definition to the data source. This data source definition 
contains the information necessary for a data source to construct and initialise its data 
5 reference object model. Once initialised, the data source returns the root of its object 
model to the data source manager. 

The data reference object model is used as input to the Hendrix data binding 
engine. However, before the binding engine transfere data to the display page it needs 
to bind to the data references. It does this according to a binding definition associated 
10 with the display page. 

Once the data source has been initialised and the binding engine has bound to its 
data references, tiie data source will be started so that it connects to the server system 
and beguis delivering data to the data binding engine. The delivery of data is actually 
performed by individual data references. 

15 When the data references are no longer required tiie data source is stopped and the 

data source closes any connections it has with the server system. The binding engine then 
release all data references. The data source manager will uninitialise the data source 
during which the data source will discard its data reference object model. The data source 
manager usually caches a data source in the uninitialised state for fiiture use. 

20 There is a one-to-one relationship between display pages and data sources. A 

data source will only ever be supplying data to a single display page. The one data 
source manager, however, is able to supply data to multiple display pages. In this case 
the data source manager is managing multiple data sources for multiple display pages. 
These multiple data source instances may make use of shared resources for 

25 communicating with tiie servo: system. This sharing of data includes flie sharing of 
physical network connections and the consolidation of data delivery to avoid the 
duplicate transmission of data that is common to multiple display pages. This behaviour 
is a data source specific implementation detail. 

A key concept in the Hendrix data delivery mechanism is that of the data 

30 reference. A data reference is an object that refers to a named data item in a server 
system. A data reference encapsulates the details of delivering the data to which it 
refers fi-om a servo: system to the Hendrix architecture. 
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A data reference typically augments the name of the referenced data item with 
the additional information required to affect the delivery of the data item. This 
additional information includes one or more of update rates, time intervals for historical 
data, additional query parameters and the like. 
5 Data references deliver data to the Hendrix architecture via property change 

notifications, OLE DB rowset notifications and events. 

A data reference has the following basic structural elements: 

1 . An ID by which it is known to the Hendrix architecture. 

2. An associated name from the servo: system namespace which identifies 
10 the data item to which the data reference refers. 

3. One or more properties, OLE DB rowsets, methods and/or events that 
represent the referenced data item to the Hendrix architecture. 

4. A set of properties that define ttie additional information required for the 
delivery of the referenced data item (also known as data deUvery properties). 

15 The ID is a read only property. The data reference ID is largely an internal 

name for the data reference and is rarely seen by end users. 
. The name is optionally a read/write property. 

Since the ID of the data reference and the name to which it refers are separate 
properties, a data reference provides a natural fomi of indirection. If the associated 
20 namespace name is changed at runtime, the data reference then refers to a different data 
item in the server system. This runtime indirection is an optional property of data 
references that is difficult to implement in some cases. If so, it is easily disabled by 
simply making the name property read only. 

The set of properties, methods and events that represent the data item to the 
25 Hendrix architecture (and can be bound to display page elements) depend on the type of 
the referenced data item. In many cases a single property that represents the value is all 
that is necessary. The value property is typically ttie default property on the data 
reference. This makes the syntax for accessing the value slightly more compact. 

A slightly more complex example is provided by data items that have an 
30 associated quality indication. In this case, the data reference includes a property for the 
value (the default property) and a property for the quality indicator. 

The data delivery properties are read only or read/write properties depending on 
the capabilities of the server system. Again the specific set of properties required 
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depends on the server system and the type of the referenced data item. The data 
deUvery properties include properties that control the transmission of data from the 
server system such as update rates or information that helps to completely identify a 
data item in cases where a name from a server system namespace is not sufficient. 
5 The foUowing example further iUustrate the basic data reference concept and its 

practical implementation. 

Consider a data reference that refers to an item in a Plantscape server caUed 
"34FC1234.PV". The data reference's ID might be ParamRefl and the associated 
namespace name would be "34FC1234.PV". Figure 16 illustrates a data source with 
10 several data references. 

The Hendrix architecture knows the value of the referenced data item as 
ParamRefl (or ParamRefl .Value). If the data item includes a quaUty indication the 
Hendrix architecture knows it as ParamRefl .Quality. 

Script code for changing the namespace, in some embodiments, takes to 
15 following form: 

ParamRefl jiame = "34FC2222.PV" 

As far as the Hendrix architecture is concerned nothing has changed, the data 
reference ParamRefl is still supplying data, but behind the scenes it is now getting data 
from another item in the Plantscape server. Of course, this impUes that the new data 
20 item in the server is of the same type as the previously referenced data item so that the 
same data reference object is used to reference it. 

Data references are also organized in a hierarchy if this better reflects the 
stmcture of server system data. A hierarchical organization allows multilevel 
indirection to occur. 

25 The following exanaple shows how hierarchical data references in an LCN data 

source provide multilevel indirection. Consider two data references that refer to 
different parameters of the same tag in an LCN system. ParamRefl refers to 
"A100.PV'' and ParamRefZ refers to "A100.SP". Figure 17 iUusti-ates this example. 

Where the desfred effect is to change both of these data references to look at the 

30 same parameters of anotiier tag, "A200", the namespace name of both data references 
could be changed as above to refer to "A200.PV" and "A200.SP" respectively. 
Alternatively, and as unplemented in some embodiments, a separate data reference is 
used for the tag name caUed TagRefl that initially refers to "AlOO" witii ParamRefl 
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and ParamRefZ now referring to *TV" and "SP" respectively. The Hendrix architecture 
then knows "A100.PV" and "AlOO.SP" as TagRefl.ParamRefl and 
TagRefl .ParamRef2. 

The following script code is all that would be required to change the references 
5 from "A100.PV" and "AlOO.SP" to "A200.PV" and "A200.SF\ 

TagRefl .name - "A200'* 

It is up to the data source to make sure that all data references below TagRefl 
now refer to the correct parameters in the server system. 

Another common application of hierarchical data references is when a data 
10 source provides data from multiple server systems simultaneously. An example of this 
is an OPC data source. In this case a data reference refers to the server and data 
references that refer to the items within the server would appear as children of the server 
reference. The associated namespace name for the server reference is, for example, the 
machine name of the OPC server and the data delivery properties for the server 
15 reference includes, for example, information required to connect to the server such as 
the ProgID or CLSID of the OPC server. 

Support for hierarchical data references is entirely optional and adds to the 
complexity of the data soxirce implementation. 

Data references are preferably organized into collections. Collections occur at 
20 any level in a hierarchical data reference. 

In some embodiments, the data references have predefined sub-objects. An 
example is a server system that supplies all relevant parameters for a given named tag 
(eg AlOO). If a data reference with the ID DataRefl refers to "AlOO" then the Hendrix 
architecture knows its parameters simply as DataRefl .PV, DataRefl .SP etc without the 
25 need for expUcit data references for each parameter. 

Data references that are appear as predefined sub-objects are referred to as 
implicit data references. 

As noted above, data references expose the data they refer to as properties. The 
basic property data types supported are VARIANT and OLE DB Rowset. 
30 The following VARIANT types are supported: 

VT_^UI1, VTJ2, VTJ4, VT_R4, VT_R8, VT^CY, VT^DATE, VT_BSTR, 
VT_VARIANT, VT^BOOL, VT^NULL, VT_ERROR 

Safe arrays of these types are also supported (VT_ARRAY | *). 
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In other embodiments of the invention a data reference also exposes data to the 
binding engine in the form of an OLE DB rowset. The rowset is exposed as a sub- 
object of the data reference. In this case the information required to estabUsh the OLE 
DB session and create the rowset is usuaUy part of the data delivery properties of the 
5 data reference. 

Further embodiments have data references that include data delivery properties 
that allow finer control over the reference that than provided by simply changing the 
associated name. An example is a data reference that refers to a single element in an 
array. In such an embodim^t, the data reference has an index associated with it in 
10 addition to namespace name. Consider a data reference with the ID ArrayRefl that 
refers to "Analyzerl.CbncentrationData". To folly identify a single element within the 
array an index is also required. The data reference definition for tiie reference includes 
an initial value for the index and it is subsequently changed using script code as follows. 
ArrayRefl .Index = 2 

15 A fiirther example of a more complex data reference is one that refers to data in 

a relational database that requires a number of SQL query parameters to fiilly specify 
tiie reference. . 

Data references exist to supply data to the data binding engine. They do this 
through property change notifications. As the data referred to by a data reference 

20 changes in the server system it is deUvered to the data reference using a server system 
specific mechanism. The data reference then notifies the binding engine that a data 
reference property has changed. The notification mechanism allows the data reference 
to pass the changed data to the binding engine as part of the notification which means 
liiat it is not necessary for the data reference to cache the data internally. There are, 

25 however, some server systems in which it is advantageous to cache the data within the 
data reference. 

In addition to providing property change notifications a data reference is used, in 
some embodiments, to also fire events. These events are mapped on to methods on 
display page elements or consumed by the binding engine. 
30 Similarly, data references are also used, in some embodiments, to also expose 

methods. These methods are typically commands associated with a particular type of 
data reference. For example, a data reference that provides access to a segment of an 
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array in a server system provides commands (methods) that allow the segment to be 
scrolled along the length of the underlying array. 

Data references are accessible from display page script code via the root of the 
data source object or via display page elements to which they are bound. Accessing the 
5 root of the data reference object model can be done as follows 

Data.data_soiirce_namespace_identifier 

Where Data is the SGML ED of the display page's data source comiector and 
data__sovirce_jiamespace_identifier identifies the data source. A more detailed example 
is as follows: 

10 Data.OPC.ServerRefl .name = *TRefinery2" 

Accessing a data reference via a display page element is done as follows: 
Ref = Alphal.DataRefs(index) 

Where index is either the ID of the data reference or the associated name. The 
IDs of boimd data references are searched first. If the associated name is associated 
15 with more than one bound data reference, the first is returned. If the display element is 
bound to a hierarchical data reference then the lowest level data reference is returned. 

Each display page has associated with it a series of data source definitions, one 
for each data source from which data is required. Each data source definition contains 
the data soirrce specific information required to construct a data reference object model 
20 that contains the data references required by the display page. . 

The data source definitions are stored in an XML document. Each data source 
definition is enclosed in a HENDRIX:DATASOURCE element This element has 
attributes that identify the namespace with which the data source is associated and the 
CLSID of the data source component. The content of the DATASOTJRCE element is a 
25 data source specific detail. At a minimum it contains information on how to construct 
data reference objects tibat reference the required namespace names. 

The format of a data source definition is assumed to be valid XML. If it is not 
vaUd XML it must be enclosed in a CD ATA section. 

The following example illustrates a data source definition for an OPC data 
30 source (CLSIDs elided for clarity). 

<HENDRIX:DATASOURCE NAMESPACE=''OPC" CLS1D="DA943720- 
8048-1 ld2-8ED5-000000000000" 

CONNECTSTRING="SERVER=OPCX. . 
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<SERVER NAME="Modbus"> 

<GROUP UPDATERATE^'5000'^ 

<!— the following corresponds to a reference to 
'OPC://Modbus.34FC1234.PV" -> 

<DATAREF ID="DataRefl" NAME="34FC1234.PV"> 
</GROUP> 
<ySERVER> 
</HENDRIX:DATASOURCE> 



10 The above example illustrates that the organization of the data source definition 

is dependent on the server system that the data source enc^sulates. lii this case the 
organization is by OPC s&rver and group. 

The following example shows how a data source definition that includes binary 
data might look. 

15 <HENDRIX:DATASOURCE NAMESPACE='XCIsr' CLSID="DA943721- 

8048-1 ld2-8ED5-000000000000"> 

<![CDATA[FE12345AB65C98AFABE192F87E2A26C... 
78C67BAE45 1F536D]]> 
</EIE]SiDRIX:DATASOURCE> 

20 

In this case the organization is not obvious because the definition is an opaque 
blob of binary data. All that matters is that this definition is meaningfiil to the LCN data 
source. 

If a data source supports hierarchical data references, the data source definition 
25 will need to include the hierarchical relationships between data references. 

As discussed above, data source definitions define the set of data references 
required by a display page. At run time, the entire data source definition is loaded into a 
data source so that the data source is able to construct the required data reference object 
model. 

During the display building process data source definitions need to be updated as 
the user adds and removes references to data in the display page. Since the user deals 
primarily with server system namespace names rather than data reference IDs, an 
important design time task is to take a server system namespace name and add a data 
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reference of the correct type to the data source definition. These namespace names 
come firom either the Hendrix namespace browser or firom direct user input. 

This task is handled by a design time component known as a "data source 
definition editor". A data source definition editor is able to add and remove data 

5 references fi*om a data source definition. They are used by the common display builder. 
They also supply property pages that are used in the common display builder to allow 
the user to configure the data delivery properties for a data reference. 

A data soiurce is an in-process COM object that implements the 
IHendrixDataSource interface. This iaterface allows the data source manager to 

10 initialise, start and stop the data source. The main purpose of the data source is provide 
a data reference object model to the data binding engine. This data reference object 
model consists of a hierarchy of data reference objects and collections of data reference 
objects. In fact the data reference object model is a standard automation object model, 
v^th the exception that a more efficient form of connection point mechanism is used. 

15 The data source is initialised with a data source definition that informs the data 

source of what data is required firom the server system. Once initialised, the data source 
is transitioned to the miming state, in which it deUvers data to the data binding engine 
via the data reference objects. 

The data source also exerts some high level control over the transmission of data 

20 fi-om the data binding engine to the display page. This is achieved via the 

HiendrixBindingEngineCache interface. This is useful when a data source wants to 
ensure that an x^date is delivered immediately to the display page, rather than cached 
for later delivery as part of a larger update packet. Figure 18 shows the relationship 
between the data soiirce manager, data binding engine and data source. 

25 A data reference is a COM object that exposes the IDispatch interface and 

supports property change notifications. OLE DB rowsets are exposed as sub-objects of 
the data reference. This allows the data reference to expose more than one rowset. 
Hierarchical data references and collections of data references are implemented using 
sub-objects in the normal OLE Automation fashion. 

30 A data reference notifies the data binding engine of changes to properties via the 

IHendrixNotify interface provided by the binding engine. Data references that fire 
events do this via IDispatch. 
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OLE DB Rowsets expose IRowset (and related intarfeces such as lAccessor, 
IConnectionPointContainer etc). An OLE DB rowset notifies the data binding engine of 
changes to the rowset via the IRowsetNotify interface provided by the binding engine. A 
rowset data reference, in some embodiments, also exposes IDispatch if it occurs within a 
5 hierarchical data reference in order to provide access the lower levels of the reference. 

Figure 19 iUustrates the relationship between a data reference that exposes a 
property, an event and a rowset to a binding object which is part of the Hendrix data 
binding architecture. 

The previous description has gone to the presentation and content aspects of the 
10 Hendrix architecture, that is the HTML/XML display page and the data source 

architecture. The addressee's attention is now directed toward the mechanism that maps 
the content onto the presentation. The data binding architecture is a key element that 
gives the Hendrix architecture much of its flexibility and power. More particularly, the 
data binding architecture provides a means of binding data to virtually anything on the 
15 display page in a very efficient manner. It also provides a very flexible data transfer 
mechanism that accommodates the transformation, combination and filtering of data 
provided by the Hendrix data source architecture. 

MSHTML provides its own data binding mechanism for binding data from 
OLE-DB data sources to HTML elements and ActiveX controls. This mechanism is 
deficient in that it expects data in a tabular form, which is inappropriate for much of the 
data required in an hidustrial HMI, and it only binds data to a limited set of properties in 
the DOM. For these reasons, the Hendrix architecture includes its own data binding 
mechanism. 

The MSHTML data binding mechanism does, however, provide good support 
for binding to HTML tables. For this reason an interface to the MSHTML data binding 
mechanism for tabular data fiiom server systems is also available. 

The Hendrix data binding architecture is based on a high performance binding 
engine fliat maps properties firom the data reference object model on to properties of 
DOM. It does this in an entirely general way so that any property in the data reference 
30 object model is mapped on to any property in the DOM. Figure 20 illustrates the broad 
components in the Hendrix data binding architecture. 

The binding engine uses a series of binding definitions suppHed fi-om the 
HTML/XML display file that defines how to map data from data reference object 



20 



25 
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models to the display page. The binding engine moves data between properties in the 
data reference object model and the display page in response to changes in those 
properties. It can move data in either direction so that data changed in flie display is 
propagated back to the data reference object model and then on to the various server 
5 systems. A speciaUsed form of data binding is OLE DB rowset binding where a rowset 
exposed in the data reference object model is mapped on to either a rowset or an OLE 
DB Simple Provider in the display page for binding to HTML tables. 

The binding engine also map events in the data reference object model to 
methods in the display page and vice versa. Binding definitions are discussed in more 
10 detail below. 

The internal architecture of the binding engine is componentised. The transfer 
of data firom the data reference object model to the display page is made through 
tranformations. The simplest form of transformation is one that directly transfers a 
property or event fix>m the data reference object model to the display page. More 

15 complex transformations include a transformation of the data in some way, or use 
several properties firom the data reference object model to derive a value that is then 
transferred to the display page. Transformations are selectively chained together to 
form more complex transformations. Transformations are either suppUed by end users, 
consultants to those users, or the provider of the system. 

20 The binding engine executes in an apartment managed by the data source 

manager while the display page executes in its own apartment Any changes to data in 
the data reference object model are detected by the binding engine which then transfers 
the data to the data source connector in the display page which applies the updates to the 
display page elements. The binding engine maintains an internal cache of updates that 

25 are transferred to the data source connector in batches to minimize inter-apartment 

round-trips and mirdmize display page redrawing. This batching of updates only occurs 
for transfers from the data reference object model to the DOM. Transfers in the other 
direction are always immediate. An important consequence of this architecture is that 
the main display page's thread's involvement in the handling of incoming data is 

30 niininiized making it more responsive to user interaction. 

Binding definitions are used to tell the binding engine how to map data from the 
data reference object model on to the display page. Binding definitions are part of the 
HTML/XML display page. There is one binding definition per display page element 
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that requires data. This organization makes it easier to manage the binding definitions 
in the common display builder. It also makes it easy to access the binding definition via 
the display page element at run time &om. script code in the display page. 

Each binding definition expUcitly defines the mapping of data fi-om the data 
5 reference object model on to the display page element. The definition takes the form of 
a HENDRIX:BINDINGDEF element. The following example illustrates the broad 
features of a binding definition. 



<!-- the display page element ~> 
10 <SPAN ID="Alphal" CLASS="Hendrix" 

BINDINGEF="AlphalBindingDef'xSPAN> 

<!— the binding definition —> 

<HENDRIX:BINDINGDEF ID="AlphalBindingDef'> 

15 <BINDINGTYPB="Property"SOURCE="OPC.DataRefl' 
TARGET="PageElement.InnerHTML"/> 

<yHENDRIX:BIlSrDINGDEF> 



<!-- the data source definition — > 

20 <HENDRIX:DATASOURCE NAMESPACE="OPC' CLSID="DA943720- 

8048-lld2-8ED5-000000000000"> 

<SERVER NAME="Modbus"> 

<GROUP UPDATERATE="5000'*> 

<!— the following corresponds to a reference to 
25 "OPC://Modbus.A100.PV" -> 

<PATAREF NAME="A100.PV" ID='T)ataRefI"/> 
<yGROUP> 

<SERVER> 
</HElSIDRIX:DATASOURCE> 

30 

Each binding definition consists of one or more bindings that define a property 
to property mapping between properties of data references and properties of the page 
element. In tiiis example tiiere is a single binding that maps data firom 
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OPC.Modbus.A100.PV to the InnerHTML property of the page element with wliich this 
binding definition is associated, in this case the SPAN element Alphal. 

Note that the type of the binding in this example is *TProperty". This is the 
default type and is omitted, as required, &om the BINDING element. 
5 The source and target of a binding are a property of a sub-object of a data 

reference or the page element, as in the following example. However, in other 
embodiments this is not the case. 

<HENDRIX:BINDINGDEF ID="GrouplBindingDef' > 
10 <BINDING SOURCE="OPC,DataRefl .PV" 

TARGET="PageElement Alphal . Value''/> 

<BINDING SOURCE="OPC.DataRefl.SP" 
TARGET='TageElement.Alpha2,Value"/> 
<;/HENDRIX:BINDINGDEF> 

15 

At run time, each binding definition results in the creation of a binding object 
within the data binding engine. 

A binding that binds an event to a method is of type "Event". If the signature of 
an event does not match that of the method to which it is bound a transformation is 
20 necessary to map the event on to the method. 

An important application of event binding is to bind a user interface element that 
generates events to methods (commands) on data references. 

The binding definitions described in above provide for a direct mapping firom 
the data reference object model to flie display page. In many cases however, the data 
25 needs to be transfonned, combined or filtered in some way before being applied to the 
display page. There are many examples where such transformations are required. One 
example is data driven dynamics such as rotation, translation, path animation and break 
point animation that is to be appUed to page elements. In these cases the data to be 
delivered to the display page is derived from data references and the result is appUed to 
30 the display page. Another example is where a value to be delivered to the display page 
is the result of some user written data driven script code as in the case of GUS data 
reference expressions and OnDataChange scripts. A further example is where an event 
is being m^ped on to a method with an incompatible signature. 
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To accxjmmodate these sorts of examples the binding engine's data transfer 
mechanism is componentised to allow it to be extended with components to provide 
arbitrarily complex transformations to be performed as data and events are transferred 
&om the data reference object model to the display page. 

The three main types of transformation are property, event and OLE DB Rowset 
transformations. Property transformations transform data. Event transfomiations m^ an 
event on to a method facilitating argument conversion and other processing. OLE DB 
Rowset transformations function as OLE DB consumers and map a rowset into either a 
set of discrete properties or another rowset. Moping to a set of discrete properties is used 
to unpack a rowset and apply its contents to a variety of display page properties, while 
mapping to another rowset is used to perform queries, sorting, filtering or data reduction 
with the result being another OLE DB rowset (simUar to the functions performed by OLE 
DB service providers). 

Transformations are objects with a series of "terminals" which are used as inputs 
and outputs to the transformation. The transformations are "wired" into the binding 
definitions. 

Transformations also include a programmatic interface that allows it to be 
configured at display building time and manipulated at run time. This interface includes 
methods, properties and events. 

The following example illustrates how, in one embodiment, a transformation 
that derives an angle of rotation fi-om a data reference is included in a binding definition. 

<!-- the display page element ~> 

<v:rect ID=»Rectl" CLASS="Hendrix" BINDINGDEF="RectlBindingDef' 
STYLE=»..."/> 

<!- the binding definition ~> 

<HENDR]X:BINDINGDEFn>="RectlBindingDef'> 

<XFORM ID="RotationDyn" DEF="CLSID:OEDB0680-81C8-1 ld2- 
8ED6-000000000000" 

PROPERTffiS="InitialAngle:0; RotationSpan:270; RangeLow:50; 
RangeHi:150"/;> 

^BINDING SOURCE="OPC.DataRefl" 
TARGET="RotationDyn. Value"/> 
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<BINDING SOURCE="RotationDyn.Angle" 
TARGET="PageElement.style.rotation"/> 
<BQBNDRIX:BINDINGDEF> 

5 <!— the data source definition — > 

<HENDRIX:DATASOURCE NAMESPACE="OPC" CLSID=''DA943720- 
8048-1 ld2-8ED5-000000000000''> 

<SERVER NAME="Modbus"> 

<GROUP UPDATERATE="5000'> 
10 <!— the following corresponds to a reference to 

"OPC://Modbus,A100.PV" -> 

<DATAREF NAME="A100.PV" ID='T3ataRefl"/> 
</GROUP> 
</SERVER> 
15 <MNDRIX:DATASOURCE> 

In this example, the binding definition includes the XFORM element which 
declares a transformation known as "RotationDyn" in this binding. The transformation 
is a binary component identified by the CLSID in the DEF attribute. The rotation 
20 transformation has a series of properties used to control the transformation firom value to 
angle. Initial values for these are specified using the PROPERTIES attribute. 

Once declared, the transformation is simply connected into the data transfer 
mechanism using two separate bindings. The rotation transformation has two terminals 
for this purpose, "Value" and "Angle". The effect of this binding definition is that the 
25 value of the referenced data item is converted to an angle of rotation and delivered to 
the rotation property of the VML rectangle. 

In this example the transfomiation was a binary component that was written in 
C-H-. However, in other embodiments use is made of this and/or other programming 
languages such as Visual Basic, Java and the like. This would be appropriate in this 
30 case since the rotation transformation could be very widely used and overall 

performance of the Hendrix architecture would benefit firom a binary implementation. 

Another option is to constmct transformations using an XML syntax and script 
code. Following, there is a description of the use of XML transformations, more detail 
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on constructing binary transfomiations, and a more conqjlex example that reproduces 
GUS functionality. 

Transformations provide an extremely powerfiil and flexible way to extend the 
Hendrix data binding architecture. The previous example, a common data 
5 transformation was packaged into a binary transformation component so that it could be 
used to provide rotation dynamics for display page elements. In the following example, 
the data transformation is one that is widely used across many different display page 
elements. This large scale reuse and the performance implications justify the inclusion 
of a binary transformation component 
10 There are many cases where a "one off' transformation is required for a single 

instance of a display page element. This is the case when a user wants to tailor the 
delivery of data to the display page using some data driven script code. A common 
example is when a page element requires a data value that is the result of some 
expression involving several data references. XML based transformation components 
15 allow ease of construction of transformations that contain user writtrai soipt that is 
executed as part of the binding engine's data transfer mechanism. 

The following is a simple example showing an XML transformation that uses 
script code to calculate the sum of two data values. 

<HENDRIX:XFORMDEF ID="AlphalDataScriptDef'> 
20 <TERMINALID="hiputl"NOTIFY="Scriptr'/> 
<TERMINAL ID="Input2"/> 
<TERMINAL ID="Result"> 
<SCRIPT ID="Scriptl" LANG="VBScript"> 
Result = Input! + Input2 

25 </SCBJPT> 

</HENDRIX:XFORMDEF> 

The XFORMDEF element contains the definition of the transformation. It has 
three terminals; Inputl, Input2 and Result. There is a script element that contains 
30 VBScript code in this example. The script code uses the terminal IDs in the calculation 
of the sum. The terminal Inputl has a NOTIFY attribute that names the script elranent. 
The effect is that any changes to Inputl will result in Scriptl executing. As will be 
appreciated by those skilled in the art, the terminal Iaput2 does not have the NOTIFY 
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attribute which means that changes in lhput2 will not result in any script executing. 
Thus, the writer of the XML transfonnation has complete control over what causes the 
transformation to transfer data. 

The usage of this transformation in a binding definition would be as follows. 
5 <HENDRIX:BINDINGDEF ID="AlphalBindingDef'> 

<XFORM ID="ScriptComp" DEF="AlphalDataScriptDef' /> 
<BrNDING SOURCE="OPC.DataRefl" 
TARGET="ScriptComp.Inputl "/> 

<BINDING SOURCB="OPC.DataRe£2» 
10 TARGET="ScriptComp.Input2"/> 

<BINDING SOURCB="ScriptComp.Result" 
TARGET="PageElement.Value"/> 

<;/HENDRIX:BINDINGDBF> 



1 5 In this case the DEF attribute of the XFORM element indicates that the 

transformation is an XML transformation defined in the current display page. The 
XML transformation, in other embodiments, is defined in a separate file in which case 
the DEF attribute might have the value "URLiAlphalDataScriptDef.xml". 
It is also easy to construct bi-directional transformations using XML 
20 transformations as the following illustrates. 

<HENDRIX:XFORMDEF ID="SignChangeDef'> 

<TERMINAL ID=^'Input" NOTIFY="Scriptl"/> 
^TERMINAL ID="Ou1put" NOTIFY="Sciipt2"/> 
<SCRIPT ID="Scriptl" LANG="VBScripf'> 
25 Output = hiput * -1 

<SCRIPT> 

<SCRIPT ID="Script2" LANG="VBScript"> 
Input = Output * -1 

</SCRIPT> 
30 </HE]SIDRIX:XFORMDEF> 



In this example two separate script elements, which perform complementary 
transformations, execute in response to changes in the input and tiie ou^ut. 
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XML transfomations also include a programmatic interfece consisting of 
properties, methods and events. The following example illustrates an XML 
transformation that provides such properties and an event. 
<HENDRIX:XFORMDEF ID="BreakPfDef > 
5 <PROPERTY ID="CurBreakPt"/> 

<PROPERTY ID="BreakPtl" NOTIFY="Scriptl'V> 
<PROPERTY ID='3reakPt2" NOTIFY="Scriptl»/:> 
<PROPERTY lD="BreakPt3" NOTIFY="Scriptl"/> 
<PROPERTY ID="BreakPt4" NOTIFY="Scriptl"/> 
10 <EVENT ID="OnBreakPt"/> 

^TERMINAL ID="Input" NOTIFY="Scriptl"yi> 
<SCRIPT ID=»Scriptl" LANG="ECMAScripf'> 
i^ataVal < BreakPtl && !(CurBreakPt = 1) 
{ 

15 CurBreakPt=l; 

FireEvent("OnBreakPt"); 
-- ■ • } . .... . 

else if(DataVal < BreakPt2 && DataVal > BreakPtl && 
!(CurBreakPt==2) 



20 { 



25 



30 



{ 



CurBreaki't = 2; 

FireEvent("OnBreakPt"); 

} 

else ifCDataVal < BreakPtS && DataVal > BreakPt2 && 
!(CurBreakPt = 3) 



CurBreakPt = 3; 

FireEvent("OnBreakPt"); 

} 

ifCDataVal < BreakPtl !(CurBreakPt = 4) 
{ 

CurBreakPt = 4; 

FireEvent("OnBreakPt"); 
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} 

</SCRJPT> 
</HENDRIX:XFORMDEF> 

5 This transformation fires the OnBreakPt event whenever the input value enters a 

new break point region. The break point regions as defined by the four properties 
BreakPtl, BreakPt2, BreakPtS and BreakPt4 control the configuration of the 
transformation and the property CurBreakPoint reflects the current state of the 
transformation. 

10 A transformation appears at run time as a subobject of the page element that it is 

associated with. This allows script code in the display page to access the 
transformation's properties and methods and receive any events it generates. This is 
illustrated in the following example which makes use of the above transformation. 
<SPAN ID="Alphal" CLASS=''Hendrix" 
15 BINDINGDEF="AlphalBindmgDefV> 
</SPAN> 

<HENDRIX:BINDINGDEF ID="AlphalBuidingDef' > 
<XFORM ID="BreakPt" DEF=*'BreakPtDef' 
PROPERTIES="BreakPtl:40; BreakPt2:80; BreakPt3:120; BreakPt4:160"/> 
20 <BINDING SOURCE="LCN.DataRefl" TARGET="BreakPt.Inpuf V> 

</HENDRIX:BINDINGDEF> 

<SCRIPT FOR="Alphal .BreakPt" EVENT=''OnBreakPt" 
LANGUAGE="ECMAScript"> 
25 switch(Alphal .BreakPt.CurBreakPt) 

{ 

case 1: SoundPlayer.Play("normal.wav"); 

break; 

case 2: SoundPlayer.Play("alert.wav"); 

30 break; 

case 3: SoundPlayer.Play("highalert.wav"); 

break; 

case 4: SoundPlayer.Play("codered.wav'*); 
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break; 

} 

<ySCRIFI^ 



5 Note that, in this example, there is no data actually transferred by the binding 

engine to the display page. Instead, the information is retrieved from the transformation 
by a display page script when the transformation generates an event. Note also that the 
transformation is actually out-of-apaitment with respect to the page element with which 
it is associated. This means that accessing the transformation incurs the usual 
10 performance penalty for such cross apartment calls. 

It is also important to note in this exanq)le that the script code in the XML 
transformation is executed in the binding engine on a thread managed by the data source 
manager, while the script code responding to the event fired by the transformation 
executes in the display page on the main UI thread. 
15 XML transformations are also used to m^ an event on to a mefliod when there 

is a mismatch between their signatures which means that the binding engine cannot bind 
them directly. The following example shows how an XML transformation is used to 
map an event with one argument on to a method with two arguments. The 
transformation supplies the value of the second argument itself 
20 <HENDRIX:XFORMDEF ID="AlphalEventXFomiDef'> 

<rERMINAL ID="hiput" NOTIFY="Scriptl"/> 
<TERMINAL ID="Output"/> 
<SCRIPT ID=''Scriptl" LANG="VBScript"> 
Method(hiput.args(l), 10); 

25 <SCRIPT> 

<HENDRIX:XFORMDEF> 



<HENDRIX:BINDINGDEF ID="AlphalBindingDef •> 

<XFORM ID=»EventXForm" DEF="AlphalEventXFomiDef' /> 
<SINDING TYPE="Event" SOURCE="TPA.DataRefl .Recalculate" 
TARGET="EventXForm.Input"/> 

<BINDING TYPE="Event" SOURCE="EventXForm.Output" 
TARGET="PageElement.Rescale"/> 
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</EIENDRIX:BINDINGDEF> 

Note that the bindings in this case are of the type "Event". The default binding 
type is "Property". 

5 Note also the use of the args collection of the 'Input" terminal. This collection 

is always available even on terminals used for properties in which case args(l) contains 

the property value. 

XML transformations are also used to alter the semantics of the default 

transformation that is implied by a binding definition that binds data directly from the 
10 data reference object model to the display page without the explicit use of 

transformations. This default transformation has an equivalent XML definition as 

follows. 

<HENDRIX:XFORMDEF ID='T>irectBindingDef'> 

<TERMINAL ID="Input" NOTIFY="Connectionl"/i> 
15 <TERMINALID="Output"NOTIFY="Connection2"/> 

<CONNECT ID="Connectionl" FROM="Input" TC>="Outpuf '/> 
<CONNECT ID="Cormection2" FROM="Output" TO="Input"/> 

<HENDRIX:XFORMDEF> 

20 The CONNECT elements form a direct connection from one terminal to another. 

In this case, the default case, the connections are notified of any changes to their source 
tonoinals creating the effect of a bi-directional connection. The semantics are changed 
by changing fhs NOTIFY attributes, adding extra connections etc. For example, a 
transformatibn that broadcasts a value to several page elements follows. 
25 <HENDRIX:XFORMDEF ID='T>irectBindingPef'> 

<THEtMINAL ID="Ihput" NOTIFY="Connectionl ; Connection2; 
Connection3"/> 

<a'ERMESrAL ID="Outputl"/> 
<TERMINAL ID="Output2"/> 
30 <rERMINAL ID="Output3"/> 

<CONNECT ID="Connectionl" FROM="Input" TO="0utputl"/> 
<CONNECT ID="Connection2" FROM="Input" TO="Output2"/> 
<CONNECT ID="Connection3" FROM="Input" TO="Output3"/> 
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<;^M)RIX:XFORMDEF> 



In this case changes in the input are propagated to the outputs but changes in the 
outputs are not propagated back to the input. This is different to the effect that would be 
5 obtained if the foUowing binding definition without expUcit binding connections were 
used. 

<HENDRIX:BINDINGDEF ID="GrouplBmdingDef' > 
<BINDING SOURCE="OPC.DataRefl» 
TARGET="PageElement.Alphal.Value"/> 
10 <BINDING SOURCE="OPC.DataRefl" 

TARGET="PageElement.Alpha2.Value"/> 

<BINDING SOURCE="OPCJDataRefl" 
TARGET="PageElenient.Alpha3.Value"/i> 
</ENDRIX:BINDINGDBF> 

15 

The following example illustrates how transformations are used to reproduce 
GUS functionality. The scenario considered is that of a text object with an 
OnDataChange script that references one data value and a rotation dynamic driven by a 
data reference ejqjression that is the svim of two other data values. 
20 Firstly, an XML transformation is defined to capture the OnDataChange script 

and the data reference expression used to drive the rotation dynamics. 
<HENDRIX:XFORMDEF ID="AlphalScriptDef' 

<TERMINAL ID="hiputl" NOTIFY=»OnDataChangeScript"/i> 
<TERMINAL ID="Outputl"/> 
25 <TERMINALID='T2iput2"NOTIFY=''DataReferenceExpr''/> 
^TERMINAL ID="Input3» NOTIFY=*T>ataReferenceExpr"/> 
<TERMINAL ID="Output2"/> 
<SCRIPT ID="OnDataChangeScripf' LANG="VBScript"> 

Outputl = Func(Inputl) 

30 <ySCRIPT> 

<SCRIPT ID="DataReferenceExpr" LANG="VBScript"> 

Output2 = h^)ut2 + Inputs 

<ySCRIPl> 
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<yEffiNDRIX:XFORMDEF> 

Inputl is the input to the OoDataChange script and Outputl is the result Input2 
and Inputs are inputs to the data reference expression and Output2 is the result of the data 
5 reference expression. This XML transformation and the biuary rotation transformation 
discussed earUer are now used in a binding definition for a display page element. 

<OBJECT ID="Alphal" CLASS="Hendrix" CLSID="..." 
BINDINGDEF="AlphalBindingDef'> 
</OBJECT> 

10 

<HENDRIX:BINDINGDEF ID="AlphalBindingDef'> 

<XFORM ID="AlphalScript" DEF="AlphalScriptDef' /> 
<XFORM ID="RotationDyn" DEF="CLSID:0EDB0680-81C8-lld2- 
8ED6-000000000000" 
15 PROPER'nES='TnitialAngle:0; RotationSpan:270; RangeLow:50; 

RangeHi:150"/;> 

<BINDING FROM="LCN.DataRefl" TO="AlphalScript.Inputl"/> 
<BINDING FROM="AlphalScript.Outputl" 
20 TO="PageElement.Value"/> 

<BINDING FROM="LCN.DataRef2" TO="AlphalScript.Input2"> 
<BINDING FROM="LCN.DataRef3" TO="AlphalScript.Input3"/> 
OINDING FROM="AlphalScript.Output2" 
TO="RotatioiiDyn.Input"/i> 
25 <BINDINGFROM="RotationDyn.Angle" 
TO="PageElement.Rotation"A> 

<HENDRIX:BINDINGDEF> 

As Avill be appreciated by a skilled addressee, given the teaching herein, a data 
30 source definition that defined DataRefl , DataRefZ and DataReB as referring to 

LCN://A100.PV, LCN://A200.PV and LCN://A300.PV respectively is also required. 

In this example, two transformations are chained together to build up the 
required combination of data transformations to achieve the desired result. 
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From the preceding description, it is clear that ejcplicit transformations are used 
when data needs to be transformed as it is transferred to the display page. The 
transformation is, in some cases, one that adds real value to the data as it is transferred - 
as in the case of a rotation dynamic - or it is, in other cases - simply to massage the data 
5 slightly into a form that the controls on the display page expect. This latter category of 
transformations is largely eliminated for the controls of the system provider or designer as 
a close correspondence between the form of the data as deUvered by data source 
components and the fomi expected by the controls on the display page is designed into the 
system. This is also possible for controls targeting a specific server system. To achieve 
10 this for controls that are reusable across provider server systems requires convergence on 
the details of the object models supplied by the various data source components. 

The present embodiments also support another desired feature of an industrial 
HMI, that being the abiUty to issue commands to the server system. These commands 
are often issued firom page elements themselves as m the case of selecting a page 
15 element and pressing a function key to call up a point detail or right cHcking a page 
element to pop up a context menu &om which an action can be selected. Commands 
are, in some embodiments, also issued fi-om the user interface framework as in the case 
of the operator entering a command into the command zone or selecting a menu item 
from the framework's menu. 
20 Part of the power and flexibiUty of the architecture used in the embodiments of 

the invention comes from the separation of content from presentation. This is achieved 
through the use of distinct data source and data transformations that free the page 
elements from most of the work involved in the provision of data to the display page. 
This has the added and unexpected benefit that data is available to be provided to any 
25 page element, not just those siq)pliedby the system designer orprovider. A similar 
^roach is taken with commands that are issued to the server system. These are 
abstracted out of page elements into distinct components that allow the commands to be 
issued from any page element, not just those suppUed by Honeywell or another system 
provider. 

30 The command architecture of the preferred embodiments also allows command 

behaviour to be associated with any page element and for commands from page 
elements and the user interface framework to be routed to the server system. 
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Commands are implemented as methods on objects in the data source object 
model. Commands are, in some cases, system wide - such as commands to change 
operator security level - or server specific - such as acknowledging alamis or calling up a 
point detail. These different classes of commands are implemented at the level of the data 
5 source obj ect model 

System wide commands are implemented on the root of the data source object 
model Server specific commands are implemented on the root node of each data 
source component object model The commands are usually accessed via script code or 
via command behaviours associated with display page elements. 
10 The Hendrix architecture allows command behaviour to be associated with any 

page element on a display page. This means, foj example, that a user is able to select a 
third party control on a page and right click on it to pop up a server specific context 
menu or press a fimction key to perform a server specific action such as point detail. 

In the Hendrix architecture this ability to associate server command behaviour 
1 5 with any page element leverages flie DHTML behaviour mechanism provided by 
MSHTML. A DHTML behaviour is a component that encapsulates behaviour that 
would normally be coded into a page element or added to it via script code. A 
behaviour component "wraps" any page elements it is applied to, extending its object 
model and run time behavioxir. This mechanism provides the means by which server 
20 specific command behaviour is extracted out of page elements in a form that is able to 
be associated with any page element. 

In practice, server command behaviours fall into several distinct categories. In 
these cases, several individual behaviours are implemented as part of the one behaviour 
component. 

25 The command behaviour component implements the standard behaviour 

interfaces such as lElementBehavior and lElementBehaviorFactory. Command 
behaviours respond to user events such as keystrokes and mouse clicks, and initiate the 
appropriate server commands when these events occur. It issues the commands via the 
command methods in the data source object model 

30 Associating a command behaviour with a page element is as simple as applying 

the behaviour to the element via the standard CSS mechanisms. The following example 
shows how a command behaviour is associated with a third party gauge control 
<!— a third party gauge control — > 



wo 01/95041 



PCT/AUOl/00706 



-59- 

<object id="alphal" CLASS="Plansct^eConunands" 

classid="cMd:36D15A51.1558-lld2-8dfA-00C(MFF010A0''style="position:^^^^ 
top:500; left 500; height: 50; width: 100"> 

<param names="needleStyle" value="4"> 
<parain name="rangeLow" value="0"> 
<param naine="rangehigh" value- '100"> 
</object> 



In other embodiments alternative associations are utilised. 
10 In the case of a user interface framework, commands are usually issued directly 

to the data source object model, although this is dependent on the user interface element 
issuing the command and the implementation strategy used in constructing the 
framework. 

The abiUly to reuse display pages as building blocks for other display pages is an 
15 important factor in minimizmg the engineering cost of developing display pages for 
Honeywell and other provider server systems. This holds is both for standard displays 
that are shipped with a system and for displays built for a customer site by consultants 
or the customers themselves. 

The Hendrix architecture provides three mechanisms for achieving display page 
20 reuse. These are encapsulation, interface extension and data reference parametetisation. 
Encapsulation refers to preparing a Hendrix display page for later reuse by storing it in a 
separate file so that it is available for being embedded or linked into a containing 
display. Interface extension refers to adding properties, methods and events to the 
display page so that it is available to be treated as a ftdly fledged component in a 
25 containing display page. This greatly increases the utility of reusable display pages. 
Data reference parameterisation refers to defining data references using tokens that are 
substituted in the containing display when the display is linked or embedded. 

Note that the previous description reUes upon the file format aspects of display 
page reuse. Display page reuse is also an important source of requirements for the 
30 Honeywell common display builder. 

A Hendrix raicapsulation is formed when display page elements are contained 
within a HENDRIX:ENCAPSULATION element and is stored in a separate file. The 
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following example the encapsulation of a span tag that displays LCN.A100.PV and is 
stored in the file SimpleFaceplate.htm 

<HENDRIX:ENCAPSULATION> 
<CONTENT> 

5 <SPAN rD="PVSpan" CLASS-^'Hendrix" 

BINDINGDEF="PVSpanBindingDefVxSPAN> 

<HENDRIX:BINDINGDEF ID='TVSpanBindingDef' /> 
<DATA ID="DataRefl" REF="LCN.A100.PV"/> 
<BINDING FROM=="DataRefl" 
10 TO='TageElement.InnerHTML"/> 

<;/EffiNDRIX:BINDINGDEF> 
<yCONTENT> 
<;/HENDRIX:ENCAPSULATION> 



15 The encapsulated display page elements are contained in the CONTENT 

element. 

An embedded instance of the encapsulation follows: 
<DIV ID="Faceplater' CLASS="HendrixEncapsulation" 
DEF="SimpleFaceplate.htm"> 
20 <!— content of faceplate appears inline here — > 

<DIV> 



The embedded ^capsulation appears as a DIV in the containing display page 
with the HendrixEncapsulation behaviour applied to it. 
25 Interface extension is achieved in the Hendrix architecture using the DHTML 

behaviour mechanism provided by MSHTML. This mechanism was briefly discussed 
earlier with reference to command behaviours. DHTML behaviours provide a general 
mechanism for extending the object model of any display page element with properties, 
methods and events. 

30 Properties, methods and events are added to an encapsulated display by adding 

an INTERFACE element to the encapsulation. The following example provides an 
illustration. 

<HENDRIX:ENCAPSULATION> 
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<INTERFACE> 

<PROPERTY ID="Propl"/> 
<METHOD II>="Methodl"/> 
<EVENT ID="Eventl"/> 
5 <SCRIPTLANGUAGE="VBScript"> 

sub Methodl(x) 

if #Enc^sulation.Propl = 0 and x > 0 then 

#EncapsulationJ''ireEvent("Eventr'); 

end sub 

10 </SCRIPT> 
<;/INTERFACE> 
<CONTENT> 

<OBJECT ID="PVSpan" CLASS="Hendiix" 
BINDINGDEF="PVSpaiiBindingDef'/xSPAN> 
15 <HElSIDRIX:BINDINGDEFID==''PVSpanBindingDef'/> 

<DATA ID="DataRen" REF='XCN.A100.PV"/> 
<BINDING FROM="DataRefl" 
TC)='TageElement.ImierHTML"^ 

</HE]SIDRIX:BINDINGDEF> 
20 </CONTENT> 

<HENDRIX:ENCAPSULATION> 



Note the use of the #Enc^sulation symbol to refer to the properties and methods 
of the current encapsulation. 
25 An embedded instance of fee encapsulation could look like: 

<DIV ID="Faceplatel" CLASS=»HendiixEnc^sulation" 
DEF="SimpleFaceplate.htm"Propl="l"> 

<! -- • content of faceplate appears inhne here ~> 
</DIV> 

30 

Note that Prop 1 is given an initial value inline in the DIV element's start tag. 
The properties, methods and events are now available on the embedded instance 
for use in script code in the containing display page as follows. 
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FaceplateLPropl =2 
FaceplateMethodl (3) 

<SCRIPT FOR='Taceplatel" EVENT^'Eventl" LANGUAGE="VBScript"> 
5 ' event handler code here 

<SCRIPT> 

An encapsulation, as used in some embodiments, includes data reference tokens 
that are used to parameterise data references that appear in the encapsulated display 
page. The folloAving illustration shows one method of parametensing the data reference 
in the previous exan^les. 

<EIENDRIX:ENCAPSULATION> 
<INERFACE> 

<TOKEN ID="PointID/> 
</INTERFACE> 
<CONTENT> 

<SPAN ID="PVSpan" CLASS="Hendrix" 
BIND]NGDEF="PVSpanBindingDef'/><SPAN> 

<HENDRIX:BINDINGDEF ID="PVSpanBindingDef' /> 
<DATA ID="DataRefl" REF="##PointID.PV"/> 
<BINDING FROM="DataRefl" 
TC)="PageElement.InnerHTML"/> 

</HiENDRIX:BINDINGDEF> 
<CONTENT> 
</EIE]SIDRIX:ENCAPSULATION> 

The data reference now includes the symbol ##PointID, which is an instance of 
the token PointlD. PointID is declared as a data reference token using a TOKEN 
element in the INTERFACE part of the encapsulation. When the encapsulated display 
30 page is embedded or linked into another display page the data reference tokens are 
given values which are then substituted into the tokenised data references v^dthin the 
encapsulated display page. 



15 



20 
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The following example illustrates how the enc^sulation is used in a containing 
display page. 

<DIV ID="Faceplatel" CLASS="HendrixEncapsulation" 
DEF="SimpleFaceplate.htm" 
5 PointrD="LCN.A100"> 
<!-- rest of faceplate appears inline here ~> 
</DIV> 

In this case the token PointID is given the value LCN.A100. 
10 When determining what data references exist in the embedded (or linked) 

encapsulation, the HoneyweU common builder performs a token pasting operation to 
con^lete any parameterised data referra^ces. 

The data reference tokens are accessible at run time as part of the embedded (or 
linked) encapsulation's object model. For example, the following line of would cause 
15 the bindings that depend on the token to be unbound and then rebound to new objects in 
the data source object model. 

Faceplatel.Tokens("PointID**) = "LCNA200" 

This assumes fliat tiie data source object model already contains the data for 
LCN.A200. The containing display page will look after this detail using the technique 
20 suggested earlier witli reference to data binding definitions. 

If token values are omitted firom an embedded encapsulation at the time it is 
embedded, the data references and binding definitions that depend on them are ignored. 
Token values are then supplied at run time causing the binding definitions to take effect 
at that time. 

25 As discussed so far in this description, the Hendrix architecture typically 

consists of a client machine on which display pages are viewed and one or more server 
systems firom which data is delivered to the client. The data is delivered to the client 
machine by the server system specific data source components and presented to the data 
source manager in the form of hierarchical object models. The data source manager 

30 consolidates the various data source component obj ect models into a single data source 
object model. The binding engine, which is also managed by the data source manager, 
then transfers the data fi-om the object model to the display page as changes occur. This 
arrangement is shown in Figure 2 1 . 
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The client portion described above is also, in the preferred embodiments, run on 
a server system. This is usually necessary in cases where a data source component does 
not include a remoting mechanism for delivering data to a separate client machine. 
Figure 22 illustrates this arrangement. 
5 These two topologies both feature a thin client and are suitable in some control 

room scenarios where conventional workstations are the norm and network connections 
are regarded as potential points of failure. 

There are, however, other topologies for the Hendrix architecture that are used in 
other embodiments. As discussed in previously, the data binding engine executes in an 

10 ^artment managed by the data source manager. The motivation for this is to offload 
the work associated with deUvering data and transforming to a thread other than the 
main user interface thread. Conmiunication between the binding engine and the display 
page is an efficient batch transfer mechanism that minimizes inter-apartment round 
trips. This spUt between the servers systems and the data soxirce manager (different 

15 machines) and the data source manager and the display page (different apartments) 
makes Hendrix a three-tier architecture. The data source manager and the components 
it manages form the middle tier. If the interface between the data source manager and 
display page is made remotable, as is tlie case in some embodiments, then a number of 
other network topologies are possible. 

20 These topologies feature a very thin client and would be suitable for very thin 

client platforms such as hand held and wearable computers. One locates the middle tier 
on one of the server systems while the other locates it on a distinct machine. These are 
illustrated in Figure 23and Figure 24. 

The thin cUent topologies allow the data source manager to be shared across 

25 display pages on the same machine while the very thin chent topologies allow the data 
source manager to be shared across displays on different machines. This allow the data 
source manager to act as a common "display database". 

Another advantage of the very thin client approach is that only the data actually 
needed on the page is sent to the client rather than all of the data required to derive the 

30 needed data, thus minimizing the volume the data commimications to the chent. This is 
important for clients operating over low bandwidth communications links. 

Having the middle tier on a distinct machine is also important where 
computationally expensive transformations are performed in transformations as occurs 
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where historical data from server systems is being prepared for a complex 3D data 
visualization. This fimctionality enables very thin clients to present the visualization 
and also avoid loading the server systems with the computational burden. 

In some embodiments the middle tier represents the ideal place for a web server 
5 used to deUver display pages to the cUents. One impUcation of this is that it is better for 
the data source definitions and binding definitions to be stored separately firom the 
display page and passed directly to the data source manager as the display page is 
delivered rather than having them passed to the client as part of the display page only 
for them to be sent back to the middle tier. 

10 There are different classes of user of an industrial HMI ranging fiom those who 

require casual access to display pages via a web browser to fliose who spend all day 
working with display pages at a dedicated console in a control room. These different 
users have different requirements for the environment in which they use display pages. 
These differing requirements are reflected in differing display page frameworks. A 

15 display page framework is generally some surrounding user interface infi^structure that 
helps the user to navigate and interact with display pages. This infrastructure includes 
menus, toolbars, status zones, alarm zones, message zones, command zones, change 
zones, and the like. Another important class of framework fimctionality is the window 
management provided by soflware such as the commercially available Honeywell 

20 Safe View product. 

The Hendrix architecture, in conjimction with SafeView, provides a rich tool kit 
for constmcting display page frameworks. Some techniques for constructing 
firameworks using the Hendrix architecture are described below. 

The simplest form of framework is no visible firamework at all. This occurs 

25 when, for example, SafeView alone is used to manage the user interface of an operator 
console. This is achieved by using the Hypertext Application (HTA) mechanism 
available in MSHTML. This allows a display page to appear standalone without any 
visible framework, much in the same way that present day GUS displays appear. 
The common model for casual access to information is the web browser. 

30 Internet Explorer provides a state of the art web browsing interface that is ideal for 

casual access to display pages. Display pages are called up by entering a direct UKL m 
the browser or by any of the other myiiad navigation tools available in this environment. 
Examples include favourites or bookmarks, navigation history and hyperlinks from 
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other display pages or from other HTML pages that are part of the general corporate 
intranet. 

In the case of a web browser, the framework in which pages are viewed is the 
regular web browser user interface. It does not include any user interface elements tiiiat 

5 are HMI specific. In general this is not a limitation. In some cases however, there is a 
need for some extra user interface elements in the display page itself to allow the user to 
interact with the process or server system in a way that would normally be provided by 
an HMI specific framework. An example of this is a minimal user interface to allow the 
user to enter commands into a command zone. This minimal user interface is, in some 

10 cases, delivered as a control on the display page whose visibility would be detennined 
by the framework in which the display page is viewed. 

Industrial process control systems, such as those provided by Honeywell, are 
used in many industrial domains. The operational environments that exist in these 
domains vary greatly depending on the nature of the processes being managed. Even , ,^ 

1 5 within a particular domain, operational requirements will vary with different operational 
policies in place at different organizations. 

As discussed above, a framework is some user interface infrastmcture in which 
display pages can be viewed, navigated and mteracted with. A framework typically 
contains user interface elements such as menus, toolbars, status zones etc. The Hendrix 

20 display page architecture itself provides a perfect mechanism for constructing these 
frameworks. This is especially tme as the Hendrix data binding architecture makes it 
easy to populate the framework with data from the server system and process. 

Third party tools are rapidly emerging with which rich HTML based user 
interfaces can be constructed. Examples of these include menus and toolbars 

25 implemented as binary behaviours for use with MSHTML. 

Display page scripting is provided by MSHTML. It supports script code written 
in any language for which an ActiveX scripting engine implementation is available. 
The most popular scripting languages on web pages are JavaScript, now known as 
ECMAScript and VBScript. Microsoft provides ActiveX scripting engine 

30 implementations for both languages. 

The one aspect of display page scripting that is provided by the Hendrix 
architecture is named data access. 
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An important aspect of providing data to a display page is that of making the 
data available to script code in the display page. In the Hendrix architecture this means 
making the data source object model accessible to the display page scripting 
environment. This is done via the data source connector which provides an object 
5 model that miirors the data source object model. This object model actually provides a 
local, standard OLE Automation version of the data source object model. As an 
optimisation, the data source connector object model is created on an as needed basis, as 
it is accessed, by executing script code. 

Script code on the page accesses data in the data source object model simply by 
10 refeniig to it via the data source connector which, for convenience, is called "Data" in 
the display page. 

Data.OPC.Al OO.SP =100 

This example assumes that the data item OPC.A1 OO.SP actuaUy exists in the 
data source object model. The earUer description on the data binding architecture 
15 describes how to make sure the data source object model contains all of flie data that 
display page script code might require. 

Robustness and stability are essential features of an Industrial HMI., The 
Hendrix architecture is designed in such a way as to minimize the impact of failures in 
HMI components. The main areas of risk are ActiveX controls in the display page, user 
20 Avritten script code in the display page, binary transformations and XML 

transformations. These are all areas where it is possible for "foreign" components to be 
introduced into the HMI. These foreign components provide a risk of catastrophic 
failure or, in less acute cases, simply take too long to execute. 

The failure of any one of these components will have a direct impact on the 
25 particular display page which those components are a part of or are servicing. The 
Hendrix architecture is designed such that the impact of any of these failures will be 
limited to that particular display page. This extends to any user interface framework 
that is managing a display page. This ensures that even if a display page fails 
catastrophically, the framework will remain intact so the user is able to continue to 
receive process and system information through the framework and/or navigate 
immediately to another display page. 



30 
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In some embodiments, special components are developed to achieve the desired 
robustness. For example, specific robust display page containers that execute a display 
page in a separate process on behalf of a user interface framework. 

The script code execution environments (MSHTML and the XML 
5 transformations) monitor the execution of script code so that code that takes too long to 
execute is identified and remedial action taken. 

Inter-display communication consists of two aspects: 
1 . Communication at display invocation time, consisting of the ability of one display 
being able to pass parameters to another when it is invoked, and 
10 2. Communication after a display is loaded, consisting of the ability to share persistent 
data between displays, and across display invocations. 

A display may be invoked in one of two ways: either in the same window as the 
calling display (such as a normal hyperlink in the browser) or in a new window. When 
it comes to passing invocation parameters to such a display, these two scenarios are . ^ 
15 slightly different. 

When changing to a new display in the same window, display parameters are 
used to transmit some kind of state information (such as the currently selected point, or 
previously entered user data) to the new display. In the Hendrix environment, there are 
a number of methods available for this purpose, the first three of which utilise web 
20 technologies: 

1 . Storing the information in a cookie as part of the document object model. 

2. Storing tiie information as stmctured XML data (available in IE5). 

3. Storing flie information on the server, by using Active Server Pages and placing the 
parameters in the hyperlink definition (e.g. 

25 http://server/new_display.htm?paraml=20&param2=30). 

4. Using flie global data repository provided by the global data repository (see below). 

As far as Hendrix is concerned, any of fliese methods are appropriate to pass 
parameters to a new display. The Hendrix architecture is designed to permit the use of 
pertinent teclmologies, but not mandate it. The architecture does not require the use of 
30 Active Server Page technology, for example, but likewise it does not prohibit its use 
where appropriate. Note that adopting a custom fomi of hyperlink (where parameters 
are passed locally on the client, for example) would not be appropriate, as the parameter 
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passing mechanism needs to function in both the web browser and the operator 
environments. 

This is not the case when displays are invoked in a separate window, however. 
In HTML, a new window is opened by a normal hyperlink, or by script, as for a single 
5 window. The difference lies in the fact that the system must detennine what frame 
window to use for the new window. Consider the following scenarios: 



hivoking Display 


Invoked 
Display 


Expected Behavior 


Display in operator 
environment 


New display 


Invoked display should be called up in 
the operator environment If custom 
frame windows are used for the 
operator environment, the new display 
should be called up within such a frame 
window. 


Display in browser 


New display 


Invoked display should be called up in a 
browser window. 


Display in operator 
environment 


Popup 
faceplate 


Popup window should be called up in 
custom faceplate frame window. 


Display in browser 


Popup 
faceplate 


Popup window should be called up in 
either custom faceplate frame window, 
or browser window without 
toolbar/menu. A ftdl browser window is 
not appropriate for popup faceplates. 



These scenarios illusfrate that flie behaviour of invoked windows is not fixed, 
and instead depends on the environment in which they are viewed and the type of 
10 display being invoked. Other scenarios are also possible. (Note that popup faceplates 
have their own specialized requirements, and are described ftulher elsewhere in this 
description). 

While the normal hyperUnking mechanism allows the new document be opened 
in a second window, it does not provide any mechanism for passing arbitrary parameters 
15 to this new document. Even more importantly, it is unable to dynamically determine if 
the new window should be created in a browser window or in a frame suited to the 
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operator environment. To create external windows, and to pass parameters to them, 
script must be used. 

There are a number of possible methods for passing parameters to a new display 
at invocation time. These include the use of client-side mechanisms such as cookies, 
5 structured XML data stores, the global data repository (described below), and even the 
use of HTML behaviours to allow a display to expose properties, methods and events. 
None of these methods, however, ensure that the parameters being passed are initialised 
before the new display begins executing. This result in displays showing invalid data 
upon invocation, and also, in more extreme cases, result in script errors. While any of 
10 these mechanisms are usable in the Hendrix architecture, the standard way to invoke 
displays and pass parameters to them is provided by the data source connector. 

The data source connector provides a method call for the creation of new 
displays, as follows: 

window2 = Data.createWindow(URL [, parameter_string ]) 
15 Where parameter_string is a single string that is capable of specifying an 

arbitrary number of named parameters. Its format is modelled on the format used for 
specifying CSS attributes in HTML, and is a semi-colon delimited list of name/value 
pairs. Each name/value pair is of the form name : value. For example: 

createWindow("display2,htm" , "paraml :LCN. Al 00.P V; 
20 servemame:chevron5"); 

create Window("display3 .htm" , "param2:*embedded string as 

parameter"*); 

The data source connector invokes the new display and passes parameters to it 
according to the following sequence: 
25 1 . The data source connector invokes a new display with the given URL 

via the method appropriate to the current environment (browser or operator). The data 
source connector is aware of whether it has been loaded in the browser or an operator 
frame, and is thus able to decide how it should create the new window. 

2. The data source connector on the new display obtains a pointer to the 
30 invoking data source connector (via the opener property of the window object in the 

DOM.) 

3. The data source coimector on the new display retrieves the parameter 
list. It does this by utilizing the IHendrixDisplayParameters interface exposed by the 
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invoking data source connector. The fflendrixDisplayParameters interface is detailed 
below. 

4. If no parametera are to be passed (the parameter list is empty), or no 
invoking display exists (the opener property is null), the new data source connector fires 

5 the OnPageLoadComplete event into the DOM. Display pages must be written such 
that no data processing can commence prior to this event being fired. 

5 . If display parameters are to be passed, the new data source connector 
retrieves the parameter string, exposes the passed parameters via its own object model 
as explained below, and fires the OnPageLoadComplete event. The page is then ready 

10 to commence nomial processing. 

The data source connector exposes parameters it has retrieved as part of its own 
object model, in the displayParameters coUectioa A collection is used, rather than 
extending the object model of higher-level objects in the DOM, to avoid the possibihty of 
namespace coUisions. Parameters are accessed by name or by index (according to the 
15 order they were placed in the original parameter string). So, for the first example above: 
vail = Data.displayParameters(0) * vail = "LCN.A100.PV" 
val2 = Data.displayParameters("servemame") . . ' val2 = "chevronS" 

The H^drix global data repository is, as its name impUes, a global repository of 
20 data which faciUtates inter-display communication. It is a component of the data source 
manager, and fimctions as a data source component, supplying the binding engine with an 
object model that is able to be bound to elements on a display page. The data repository is 
thus 'global' in llie sense that all displays served by the data source manager are able to 
access its data. For a single-node systan (refer to Figure 22) this implies that the data is 
25 machine-wide. In the case of a distinct middle tier, however (refer to Figure 23), this 
impUes the ability to share display data across nodes. The global data repository 
repKcates Ihe fimctionaHty of the Display Database found in GUS systems. 

The Hendrix global data repository has a number of requirements, in that it: 

1 . Allows the user, through script, to store values m a global repository, 

30 &om where those values are retrievable by other displays running on the machine. This 
global data must remain available even after the display is terminated. 

2. Allows the user to store values in a local repository. Data in the local 
database has a hfetime dictated by the Ufetime of the display itself- when the display is 
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unloaded or changed, ihe local data is lost. The original reasons for a local repository 
were for migration from LCN to GUS. In many ways a local database is no different 
from user-dejBned variables in script on a page, and for those embodiments where 
migration issues are solved, then it would not be required. 

5 3. Allows the user to bind to data values stored in the data repository. This 

means that one display (or even an extemal application) is able to drive the data shown 
on a second display simply by changing values in the data repository. 

4. Allows the user to store references to data as variables in the database. 
These variables are updated live to reflect real process values in a target system. 

10 5. Allows objects on a page to bind to data references in the global data 

repository. In GUS terminology, this means the abiUty to reference objects in the global 
data repository in the body of an OnDataChange script. In the Hendrix architecture, this 
translates to the ability of the binding engine to map data from the global data repository 
on to the page. 

15 The above describes how the first three of these requirements (related to storing 

simple variables) are implemented in the Hendrix architecture. The ability to store 
references in the repository is discussed elsewhere. 

Access to the global data repository is provided by the data source connector on 
each page. This object provides script on the page access to the data repository 
20 functionality via the DOM. The global data repository is based around a name-based 
collection of user-definable variables, rather than a fixed set of attributes. The user is 
able to define their own database variable names, allowing for greater flexibility. 

The data source connector has three methods related to the storage of simple 
variables (Add, Item, Remove) and one property (count). These function as follows: 
25 Data.Add: 

Adds a new item, in the form of a named variable, to the global data repository. 
The syntax for this operation is: 
Data.Add(name, value) 

where name is a string, and value is a variant. For example: 
30 Data.AddCValOr', 97.2) 

Data.Add("val02", "string^value") 

DataJtem 
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Retums the specified item from the global data repository. The syntax for this 
operation is: 

DataJtem(name) 
For example: 
5 savedValue == Data.Item("val01") 

Data.Remove 



Removes an item from the global data repository. The syntax for the operation is: 
Data.Remove(name) 
10 Data.count 

Returns the number of user-defined variables in the global data repository 
collection. 

In addition to providing a global repository of data, in which stored variables 
and data refwences remain persistent across page changes, the data source coimector 
15 also provides local storage to display pages. Data stored in the local database only 
exists during the life of flie display, and is accessible by any object in the display. The 
names of items in the local database are only visible to the display using them. 

A display's local database possesses the same functionality as the global 
database. It is accessed using the DataXocal sub-object, using the same functions as the 
20 global database. For example: 

DataXocaLAdd("val01", 97.2) 

Data.Local.Item("val01") 

Data.Local.Remove("entityl") 

Data.Local.count 

25 

The Hendrix architecture also provides the ability to bind to data items in the 
data repository. This is accompUshed via the normal data binding mechanisms, with 
the implication that the global data repository functions as a data source component, 
managed by the data source manager. This aspect of the architecture is illustrated in 
30 Figiu:e25. 

The binding definition for an object boxmd to data in the data repository is 
relatively straightforward. For example: 
<BODY> 
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<SPAN ID=="Alphar' CLASS="Hendrix; PlantscapeCommands" 
BINDINGDEF="AlphalBindmgDef'> 
</SPAN> 

<HE1SIDRIX:BINDINGDEF ID="AlphalBindingDef' > 
5 <DATA ID="DataRefl" REF="Data Jtem(*valOr )"/> 

<BINDING SOURCE="DataRefl" 
TARGET='TageElement.IimerHTML'7> 

</HENDRIX:BINDINGDEF> 
</BODY> 

10 

The global data repository also allows the user to store references to process 
data, which, when retrieved by a display page, reflect real process variables in a target 
system. For example, there are circmnstances where a user requires to store the value 
of LCN.AIOO.PV in the display database variable ^VarOl", and have this variable o:^: 

15 updated automatically to reflect the value of the process variable. This process is 
substantially different from the ability to store simple values. 

As described above, the data repository behaves like a data source component 
when it comes to simple values. For data references, however, this is not the case. Data 
references must continuously retrieve data from the server system, thus placing a load 

20 on bandwidth. As items in the data repository are globally persistent, this means that 
valuable bandwidth could be taken even when no displays are loaded on a machine. 
This is clearly undesirable. Ideally, data should only be being gathered by data source 
components when that data is required in some form by a currently loaded display. 
To realise this optimisation, the data repository does not behave as a data 

25 source component for data references, but as a data source dictionary. It provides a 
dictionary service to the data source manager, which in turn allows data source 
components to achieve a form of data indirection when the page is loaded. This 
facility is explained elsewhere in the specification. To a user, however, the ability to 
access data references appears no different from the ability to access simple values in 

30 the repository, as explained below. 

Data references are stored in a similar way to simple variables, through a set of 
three methods (AddRef, ItemRef, RemoveRef) and one property (countRef). These 
function as foUowsf: 
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Data.AdclRef 

Adds a new item, in the form of a named variable, to the display database. The 
syntax for this operation is: 

Data.AddRef(name, value [, xml_data ]) 
5 where name is a string, and value is a string name representing either a 

parameter or an entire object in the data source object model. If an entire object, it is 
assumed any properties or sub-objects are implicitly included in the display database. 
For example: 

DataAddRefCValOr', 'TCN.A100.PV") ' parameter reference 
10 Data.AddRefCVal02", "LCN.A100'0 * entity (or object) reference 

The optional parameter, xml^data, is an XML structure defining server-specific 
information pertaining to data collection (e.g. update rates, collection groups, etc). 
DataJtemRef 

15 Returns the specified item from the display database. The syntax for this 

operation is: 

Data.Item(name) 
For example: 

savedValue = Data.ItemRef("val01") 
20 savedValue2 = Data.ItemRef(' Val02"),PV 



Some data source components may have pre-defined server-specific entities 
intended to represent certain aspects of the server system. As data references are 
stored as strings, any syntax may be used to reference these items. For example: 
25 Data.ItemRefCVal03'^*XCN.$AL_ENTY'') ' server-specific entity, 

Data.RemoveRef 

Removes an item fix>m the display database. The syntax for the operation is 

Data.RemoveRef(name) 

Data.GountRef 

30 Returns the number of user-defined data references in the display database 

collection. 
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Display page objects are also, in some cases, bound to references in the data 
repository, the same as simple variables. For example, the following binding 
definition is used to bind an object to the data reference stored in the item "valOl": 
<BODY> 

5 <SP AN ID="Alphal " CLASS="Hendrix; PlantscapeCommands" 

BINDINGDEF="AlphalBindingDef'> 
</SPAN> 

<HENDRIX:BINDINGDEF ID="AlphalBindingDef' > 

<DATA ID="DataRefl" REF="DataJtemRef(*valOr)"/> 
10 <BINDING SOURCE^"DataRefl" 

TARGET='TageElement.InnerHTML"/> 

</HENDRIX:BINDINGDEF> 
</BODY> 

15 As mentioned previously, the data repository does not actually store references 

to data, in an attempt to reduce possible bandwidth usage. Instead, it supplies a 
dictionary of reference infomiation that the data source manager uses to look up when 
a page is loaded. A typical sequence is as follows: 

1 . Initial display stores a reference to "LCN.A100.PV" in the data 
20 rq)ository reference "valO 1 

2. Subsequent display is loaded, with a reference to "DataJtemRefCvalOl ') 
in its data definition, along with the usual fixed data references (e.g. LCN.A101 .PV). It 
passes fliis data definition to the data source manager. 

3 . The data source manager detects that an indirect data reference fhrougji 
25 the data repository is required. It queries the data repository to resolve this to a reference 

to actual data. 

4. The data source manager then hands the fiiUy-resolved data source 
definition to the appropriate data source, which then constracts its part of the data 
source object model. 

30 5. The binding engine binds directly from the data source component to the 

page. No binding is performed from the data repository to the page. 

Figure 26 schematically illustrates the sequence of events upon page callup. 
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In this scenario, dynamic data is only retrieved by a data source component 
when it is required by a page. When the page is unloaded, the data source component 
unloads any referenced data from its object model. The only persistent data is the 
dictionary lookup information in the data repository that maps "valOl" to 
5 "LCN.A100.PV". 

This process results in efficient use of communications bandwidth between data 
source components and their respective servers. It does, however, bring into question 
the issue of perfomiance. For systems where the moping between human-readable 
data reference name and actual machine identifier is slow, a performance penalty will be 
10 paid every time a page is loaded. This performance penalty is avoided by allowing the 
data repository to store pre-binding information along with the dictionary item. 

This concept is shnilar to the abiUty to perform a pre-binding step in the 
builder. For data defined at build time, the data source component supplies a service 
to the builder which translates the human readable data tags into machine identifiers. 
15 This server-specific information is then stored with the data definition, and passed to 
the data source component at runtime to enable fast callup of the page. In the case of 
the data repository,, the situation is similar. When the data reference is fust defined 
(via a call to Data. AddRef), the data source manager queries the data source 
component for any pre-binding information it may supply. This pre-binding 
20 information is then stored in the repository along with the dictionary item. On page 
callup, when the data reference is actually required, the pre-binding information is 
passed to the data source component in order to ensure fast retrieval of the data. 

At runtime, it is possible for a display to change the reference stored in the data 
repository. In the above example, with a page element bound to "LCN.A100.PV" via 
indirection through "valOl" in the repository, the following script code is executed on 
the display: 

Data.AddRef('Val01", 'XCN.A200.PV") 
This script not only alters the dictionary reference stored in the repository, but 
also re-bind any page elements currently bound to LCNAIOO.PV to LCN.A200.PV. 
30 This implies the following capabilities of the architecture: 

1 . The data source component must be able to incrementally add 
LCN.A200.PV to its object model. 



25 
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2. The data repository must be aware that page objects are currently 
bound to objects in the data source object model via an indirection through "valOl", 
and inform the data soxirce manager when its value changes. 

3. The binding engine must be able to dynamically re-bind to the new 
5 data element. 

Dynamic binding (in which bindings between data objects and page elements 
are modified at runtime) differs from static binding (in which bindings are defined at 
build time and created when the page is initially invoked). To achieve dynamic 
binding, the binding engine exposes the IHendrixDynamicBinding interface. The data 
10 source manager uses this interface at runtime to tell the binding engine to set up a 
binding between data and a new object in the display database. 

Popup window fimctionaUty differs slightly from more generic inter-display 
communication, in fhat the invoked popup window generally encapsulates specialized 
functionality, and is expected to behave differently on screen from a normal display . ^. 
15 window. Examples of this include faceplates, where extra functionality is required to 
determine which faceplate to invoke, as well as complex lifetime management for 
push-pin type popup windows. 

The invocation of popup windows involves several distinct areas of 
functionaUty, each of which imposes requirements on the Hendrix architecture: 
20 Identification 

A standard method is required for identifying which popup window needs to 
be invoked. In the case of faceplates, this will depend on the currently selected object, 
or tag name in the system. 

Invocation 

25 The architecture must accommodate a standard method for the invocation of 

popup windows. 

Position management 

In some systems, operators are accustomed to activating a large nmnber of 
modeless popup windows. When multiple displays are shown on a single machine, 
30 some way must be provided to manage these popup windows. 
Lifetime management 
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Popup windows must have the abUity to be "push-pinned", so that they are not 
terminated when the originating display changes. The architecture must provide 
lifetime management services to facilitate this functionality. 

Preferences 

5 The TPA system requires the ability to "store" an arrangement of faceplates for 

a display, so that when the operator returns to that display the airangement of 
faceplates reappears in the configured positions on screen, without having to be 
invoked individually by the operator. 

The above limitations are now discussed in more detail with reference to the 
10 way in which the preferred embodiments of the invention accommodate these 
limitations. 

The ability to identify which faceplate to invoke for a given pomt or tag, or 
object on a display, must be accessible from script, and also activated inherently as 
part of the architecture (for examplci when a screen object is double-clicked). 

Fhst consider the scripting case. When the pomt name is known, the associated 
facq)late name is retrieved by a simple call on the data source connector: 
faceplateName = Data.getFaceplate(point_name) 

where both point_name and faceplateName are strings. The point identifier 
must be fully quaUfied, in that it identifies the data source on which the point resides 
("LCN.AIOO", for example). The faceplate name is a URL. 

At times, however, the point name will not be known, and the user will want to 
detemiine the faceplate associated with an HTML element dhectly. This functionaUty 
is provided by the same method on the data source connector, only taking a reference 
to an element in the DOM instead of a string: 

feceplateName = Data.getFaceplate(element) 

The element is specified directly via the element ID, or by specifymg its 
position in the DOM (documentgroupl.textl, for example). 

The above methods provide the abiUty to identify a feceplate name via script. 
In general, however, it is preferable that faceplate invocation is not handled through 
script on a page (as it would then need to be written for every object on that page), but 
instead as an inherent part of the architecture. This capability is provided by a binary 
HTML behaviour, which is then applied to all objects on a page. The behaviour is 
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then responsible for the method of invocation (right-click, double-click, etc.), for 
identifying which faceplate to invoke, and the invocation itself. 

In the case of a binary behaviour, the method used to retrieve the faceplate 
name is still the same: method calls on the data source connector. It is envisaged that 
5 the faceplates are invoked as part of a converged user interface, although as to how 
these behaviours are standardized across all Hendrix implementations is not relevant. 
This is a matter for the style guide and has no impact on the architecture. 

Note also that this method of faceplate identification places specific 
requirements on the architecture components, as follows: 
10 1 • The data source connector must expose the getF aceplate method call. 

2. The data source manager, and specific data source components beneath it, must be 
able to map a point name to a faceplate name, to enable the first type of call to 
getFaceplate to work. 

3. The binding engine must be able to provide a backward mapping from an object in., 
15 the DOM to the data object which is driving it. The data source component, 

subsequently, must be able to map this data object into a point name, to honour the 
second type of call to getFaceplate. 

There are two types of popup window generally required to be called from 
script - faceplates representing point details, and data entry dialog boxes intended to 
20 return information to the calling window. These are each invoked in different ways. 

A dialog box is either modal or modeless. A modeless dialog box, constructed 
from HTML, is no different from activating a separate display window. In the pure 
HTML world, this would be accomplished by a call to window.open, with parameters 
used to specify that no toolbar, menus, etc are required in the invoked window. In the 
25 Hendrix architecture, this is accomplished with a call to Data.create Window. The 
data source connector needs to be aware of its environment, to decide whether to 
create the window in a browser window or an appropriate framework window. The 
need to be able to create a modeless dialog window, however, adds extra reqvurements 
to the create Window method, namely that it accepts the same parameters as the 
30 window.open method, allowing the creation of modeless dialog boxes in the web 
browser environment. Thus the full syntax of the createWindow method is: 
window2 == Data.createWindow(lIRL [, parameter_string 
[,name 
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[, features 
[.replace]]]]); 

where URL and parameter_string are explained above, and name, features, and 
replace are the same as the parameters used in the window.open method. Information 
is passed between the dialog box and the calling window as described above. 

To create a modal dialog box in a normal HTML page, the 
Avindow.showModalDialog method is called. Similar to the case for opening separate 
windows, however, the appearance of the invoked modal dialog depends on the 
environment in which it is invoked. In the browser environment, it is acceptable to 
display the standard Internet Explorer dialog, but in the operator enviromnent a more 
custom frame may be required. Thus the data source comiector exposes the following 
method: 

variant = Data.showModalDialog(URL [. vArguments [, sFeatuies]]) 
1 5 Here the parametCTs are the same as those used in the 

window.showModalDialog method - the only difference is that the frame used for the 
invoked dialog box is dependent upon the environment. . 

Faceplate windows are different, in that a faceplate has no parallel in the 
HTML world. The frame window used for faceplates includes, for example, a 
pushpin button to allow faceplates to be kept on the desktop even as the underlying 
page changes. The frame window used for faceplates will be the same in both web 
browser and operator environments. Faceplates themselves will be created in HTML. 

The invocation of a faceplate is executed as a method call on the data source 
connector. This call often takes multiple forms: 

window2 = Data.showFaceplate(sURL [, parameter_string [, sFeatures ]]) 
window2 = Data.showFacq)late(point_name [, parameter_string [, sFeatures]]) 
window2 = Data.showFaceplate(object [, parameter_string [, sFeatures ]]) 

The first of these calls simply specifies the faceplate filename (which may 
30 have been previously retrieved by a call to getFaceplate), and an optional display 

parameter string, using the same method outlined for passing parameters as mentioned 
above. It also accepts the optional parameter sFeatures, which is used to specify 



20 
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position information on screen, and is identical to the parameter of the same name in 
the showModalDialog method in the DOM, 

The second method passes a string specifying a point name. In this method, 
the showFaceplate call is responsible for detemiining which faceplate to invoke, 

5 removing the need for the user to call getFaceplate separately. 

The third method also removes the need for a separate call to getFaceplate. In 
this case, an object in the DOM is passed as a parameter, instead of a string specifying 
a point name. Again, the data source connector is responsible for determining which 
faceplate to show, and then invoking that faceplate. 

10 Position management is an issue for faceplates in the TPA system, where 

faceplates move when the main display window is moved, minimise when the main 
window is minimised, and are constrained to the client area of the parent window. 
This is not an issue for most other systems (GUS utilizes its own desktop management 
system in SafeView, for example, and PlantScape conforms to the standards used in _ 

15 Microsoft products, where a modeless push-pinned dialog is moved independently of 
its parent window). For a system utilizing a large number of faceplates displayed at 
any one time, however, such as TPA, these solutions are not sufficient, and some form 
of position management system is required. 

Almost any type of faceplate window behaviour can be achieved, as long as the 

20 faceplate window has access to the window handle of its intended parent If the 
faceplate declares itself as an MDI child window, it will behave as such, even if the 
parent is not an MDI application. This is the case for TPA faceplates. If the faceplate 
declares itself as a normal child window, it wiU minimize with the parent window, but 
not be constrained to the parent client area. And if the faceplate is a normal window, 

25 but sets its parent window to the calling display, it will minimize with the parent, but 
not be constrained to the parent client area, and move independently of the parent. 

The key to this functionality is obtaining the window handle (HWND) of the 
application containing the calling display. This is simple in the operator environment, 
as the data source component (which creates the faceplate in its showFaceplate 

30 method) is able to obtain this window handle from the framework. In the browser 
environment, however, this is not possible. This constitutes yet another differentiator 
between the two environments — faceplates are not as easy to manage in the browser 
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enviromnent As faceplates are generally associated with process-control type 
functions, this is an acceptable compromise. 

The mechanism used by the data source connector to set the parent window on 
the invoked faceplate is simply as a property set on the faceplate object - it must 
5 expose the parentHWND property to be set by the data source connector. It is up to 
the faceplate object to decide how it uses tliis window handle, which in turn dictates 
' its behaviour. (It will be quite feasible to build a generic faceplate container, which 
depends on information in the individual faceplate HTML definition to decide which 
behaviour to exhibit. Thus TPA faceplates could function differently fiom PlantScape 
10 faceplates, while still using a single faceplate container window). 

Lifetime management of faceplates is an issue in the case of the pushpin 
fiinctionaUty required by the TPA system. Nomially, when a faceplate is invoked, it 
is destroyed when the operator changes displays. If the faceplate is "pinned", 
however, it will remain visible across page changes. If it is subsequently "unpinned", 
15 the next page change will destroy the faceplate. The mechanism used in Hendrix to 
inform faceplates of page changes is as follows: 

1 . The data source connector on each page retains pointers to each 
faceplate object it has invoked. 

2. Upon page change, the data source connector informs each of these 
20 faceplates that the page is changing. 

3 . The faceplates return a result to the data source connector indicating 
whether they have destroyed themselves or not, depending on their pushpin state. 

4. The data source connector updates its array of pointers to indicate the 
remaining faceplates, then persists this information so that it can be retrieved by the 

25 data source connector on the new display. (The ability to persist COM pointers across 
page changes is akeady possessed by the data source connector, as connection 
information also needs to be persisted across page changes, so that a new page can 
connect to the same data source as the previous page). 

5. The data source on the new page retrieves the pointers to the faceplates it 
30 needs to manage, so that it can subsequently inforai them when it is bemg destroyed. 

Preferences, where they pertain to faceplates, concern the ability of an operator 
to define a set of faceplates that they want to be called up each time a particular display 
is invoked. This is done in a similar way to the hfetune management of faceplates. The 
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data source connector on a page already retains an array of pointers to the faceplates it 
has invoked. When asked to persist preference information, it requests configuration 
information from these faceplates (such as position, point name, etc.), then persists this 
information in a structured XML data store. This information is stored on a per-user, 
5 per-display basis. It then exposes a method, showPreferenceFaceplates, which will 
retrieve this information and invoke the faceplates, in the required positions, as required. 

In summary, then, the last three functionalities impose certain requirements on 
both the data source connector and the faceplate object as used in the preferred 
embodiments. These requirements are as follows: 
10 • The faceplate object must expose the queryDestroy method, which is called by the 
data source connector when it is being unloaded. This metliod returns a value 
indicating whether the faceplate did, in fact, destroy itself. (The faceplate must also 
expose a destroy method, which destroys the facqplate regardless of pushpin state.) 

• The data source coimector must e^ose the showPreferenceFaceplates method. 
15 • The data source connector must expose the persistFaceplatePreferences method, 

which will cause it to queiy all open faceplates for their position information, and 
store this information in structured XML data. 

• The faceplate object must expose methods which returns configuration infomiation 
(such as current position on screen, as set by the operator, and current point name). 

20 The data soiwce coimector calls these methods when storing faceplate preferences. 

• The faceplate object must expose the parentHWND property, which, when set, it 
will use to create itself as a child of fliat window. 

The following features are set out to provide the addressee with some 
additional insight into the architecture of the preferred embodiments. 
25 IHendrixBiiiding 

[ object, uuid(11877500-CA13-llD2-B6EA-OOC04FF010AO) ] 

iuterface IHendrixBiading : lUnknown 

{ 

//TBD 

30 }; 



IHendrixBinding is implemented by the blading engine's internal binding 

objects. 
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IHendrixBindingEngineCache 

[ object, umd(11877501-CA13-llD2-B6EA-O0C04FF01OA0) ] 

interface MendrixBindingEngineCache : lUnknown 

{ 

HRESULTFlushO; 

HRESULT QueiyMode([out]BOOL *pbCacheOn); 
HRJESULT SetMode([in]BOOL bCacheOn); 

}; 



IHendrixBindingEngineCache is implemented by the Hendrix data binding 
engine to allow data sources to control the binding engine's transmission cache. This 
cache is used to bufifer updates to the display page to minimize round trips between 
the binding engine and the display page. 

IHendrixCoIlection 

[ object, uuid(l 1877502-CA13-1 1D2-B6EA-00C04FF010A0) ] 
interfece IHendrixCoIlection : IDispatch 

{•• - • . 

); 



IHendrixCoIlection is implemented by collection subobjects. It is an empty 
interface used as a type indicator for the binding engine navigating the object model 
via IHendrixDataRef. 

IHendrixConnectionPoint 

[ object, uuid(l 1877503-CA13-1 1D2-B6EA-0OC04FFO1OA0) ] 

interfece IHendrixConnectionPoint : lUnknown 

{ 

HRESULT Connect([in] riid, 

[in, iid_is(riid)]IUnknown *pNotifySink, 

[out]DWORD *pdwCookie); 
HRESULT Disconnect([in]DWORD dwCookie); 

}; 
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IHendrixConnectionPoint is an improved version of the standard connection 
point mechanism. It requires only one transaction to establish the connection. 
IHendrixDataRef 

[ object, uuid(l 1877504-CA13-11D2-B6EA-0OC04FF01OAO) ] 
5 interface IHendrixDataRef : IDispatch 

{ 

typedef struct 
{ 

REFIID riid; 

10 [iid_is(riid)]IUnknown *pSubObject; 

} SUBOBJ; 



HRESULTGetSubObjectsOfNames([in,size_is(cNames)]OLECB[AR 
**rgszNames, 

1 5 [injunsigned int cNames, 

[in]LCID Icid, 

[out,size_is(cNames)] SUBOBJ *rgSubObjects); 

}; 



20 IHendrixDataRef is implemented by objects in the data source object model. 

It is an extension of the standard IDispatch interface that allows the object hierarchy to 
navigated more quickly. 

IHendrixDataSource 

[ object, uuid(11877505-CA13-llD2~B6EA-00C04FF010A0) ] 
25 inter&ce IHendrixDataSource : lUnknown 

{ 

HRESULT Init([in]IHendrixBindingEngineCache *pCache, 
[in]IStream *pBindingDefStream, 
[outjIHendrixDataRef **ppDataSourceRoot); 
30 HRESULT StartO; 

HRESULT StopO; 

}; 
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IHendrixDataSource is the main interface cjqjosed by a data source. It allows 
the data soiirce manager to initialize, start and stop the data source. 
IHendrixDataSourceManager 

[ object, uuid(11877506-CA13-l 1D2-B6EA-OOC04FF010AO) ] 

interface BHendrixDataourceManager : lUnknown 

{ 

//TBD 

}; 



1 0 IHendrixDataSourceMmiager is the main interface exposed by the data 

source manager. It is used primarily by the data source connector in the display page 
and by any run time frameworks managing display pages. 
mendrixNotifySink 

[ object, uuid(l 1877507-CA13-11D2-B6EA-O0C04FFOIOAO) ] 
15 interface IHendrixNotifySiiik : lUnknown 

{ 

HRESULTOnChange([in]DISPIDdispid,' . 
[inJVARIANT newVal); 

}; 

20 

mendrixNotifySink is implemented by the binding engine's internal binding 
objects. It is used by data reference objects to notify the binding engine of changes to 
property values. 

The next part of this docimiait provides a description of the Hendrix data 
25 source architecture. In particular, it describes the components and interactions 
relevant to any data source implementation. There is provided an overview of the 
architecture and how data sources relate to the rest of the Hendrix architecture as well 
as a description of the components that comprise a data source in detail including ' 
required interfaces and interactions with other components. 

30 This document focuses on the implementation ofHendrix data sources. A data 

source is a component that exposes data, events and methods provided by a specific 
server system to the Hendrix data binding engine. The data binding oigine then 
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provides the means by which these data, events and methods are bound to the 
presentation elements in a display page. 

A data source provides a means of encapsulating all of the mechanisms 
required to access a server system from an HMI. It encapsulates the mechanisms for 

5 establishing and securing connections to a server system, delivering data to and from a 
server system, delivering events from the server system to the HMI and invoking 
methods on the server system from the HMI. 

A data soxirce implementation of the preferred embodiments actually consists 
of two main parts. The first is the data source component itself, which is responsible 

10 for the overall operation of the data source such as estabUshing connections to server 
systems and persistence of the data source. The second part is a hierarchy of data 
objects, called the data object model, which exposes the server system data, events 
and methods to the Hendrix data binding engine. The data source component also acts 
as the root of the data object model. Figure 27 illustrates the general arrangement of 

15 the Hendrix data source architecture. 

A Hendrix user interface framework hosts one or more display pages. A user 
interface framework uses the services of a Hendrix data source manager to manage a 
set of data sources that supply data to the display pages it hosts. The data source 
manager provides an execution environment for data sources that includes a nxmiber 

20 of services that they require in order to provide efficient, secure access to data. 

Hendrix data sources, as used in the present embodiments, are in-process COM 
objects. They belong to the Honeywell Data Source component category identified by 
the following GUID. 

CATID^HDXDataSource = {E2156A20-640F-lld3-B766-OOC04FF010AO} 

25 This component category is used by int^ested parties (e.g. the Hendrix display 

builder) to learn what data soxirce implementations are available on a system. 

Figure 28 illustrates the components that constitute a data source, the main 
COM interfaces they implement and the main relationships they have with other parts 
of the Hendrix architecture. 

30 Tlie only extemally createable object in a data source implementation is the data 

source factory. The data source factory is a regular COM object (not a class object) that is 
used to manufacture instances of a particular data source implementation. The data 
source factory is cached by the data source manager for the Ufetime of the data source 
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manager and provides an opportunity for a data source implementation to share resources 
such as network connections between data sources (concurrently and serially). A regular 
COM object is used rather than a COM class object to enable data sources to be 
implemented in Visual Basic. The data source factory implemCTits 
5 IHDXDataSourceFactory, which is used to manufacture a new data source instance. 

The main COM interfaces implemented by a data source are IHDXDataSource 
and IHDXDataObject. IHDXDataSource allows the data source manager to access 
the methods that control the overall operation of the data source. IHDXDataObject 
allows the data source manager to access the methods used to control individual data 
10 objects in the data object model. 

Data sources and data objects implement a mmiber of other COM interfaces to 
complete the functionality required by the data source manager and clients of the data 
source manager. These interfaces are described in further detail below. 

Hendrix data sources expose a set of standard properties that control their 
15 behaviour in various circumstances. There are currently two standard properties 
defined, these are "SimulatedData" and "QualityOfService". 

SimulatedData is a boolean property whose value indicates whether or not the 
data source should deUver real or simulated data. Typically, SimulatedData is set to 
TRUE when the cUent of the data source manager is the Hendrix Display Builder and 
20 set to FALSE when the client of the data source manager is a run time framework. 

QualityOfService is an enumeration that indicates to the data source what 
quality of service is desired. Control room operators would typically require a high 
quality of service, while a lower quality of service might be adequate for more casual 
users. 

25 It is up to each data source implementation to decide exactly how it will 

respond to the various values of these properties. It is expected that this set of 
properties will expand over time and the architecture allows for this expansion. More 
information on standard data source properties is provided below. 

Each data soiurce has a site object through which it accesses a variety of 

30 services. These services are exposed as a set of ambient properties accessible via 

IDispatch on the site object. The services provided by the site object currently include 
a data transfer service, a security service and an error logging service. 



